I have a scenario where I have two different entrypoints in my application (two deployables). I want to test these separately. Here is my config file
{:kaocha/tests [{:kaocha.testable/type :kaocha.type/clojure.test
:kaocha.testable/id :suite-a
:kaocha/ns-patterns ["-test$"]
:kaocha/source-paths ["src/a"]
:kaocha/test-paths ["test/a"]}
{:kaocha.testable/type :kaocha.type/clojure.test
:kaocha.testable/id :suite-b
:kaocha/ns-patterns ["-test$"]
:kaocha/source-paths ["src/b"]
:kaocha/test-paths ["test/b"]}]
:kaocha/fail-fast? false
:kaocha/color? true
:kaocha/reporter [kaocha.report/dots]
:kaocha/plugins [:kaocha.plugin/capture-output]}
This works as expected:
lein run -m kaocha.runner suite-a
But, if I try doing it from the REPL
(kaocha.repl/run :suite-a)
it seems to be running both test suites.
I was able to hack around it using this
(kaocha.repl/run (update (kaocha.repl/config)
:kaocha/tests
#(filter (fn [{suite-id :kaocha.testable/id}]
(= suite-id :suite-a))
%)))
but I don't know what I'm doing wrong. Is this a bug?So assuming I have the following midje test:
(tabular
(fact "Should throw exception on invalid layout string"
(parse-layout-string ?row-layout [?layout-string]) => (throws Exception))
?row-layout ?layout-string
false "[]"
false "[x]"
false "[x"
false "x]"
false "[x][c][r]"
false "[l][x][r]"
false "[l][c][x]"
false "{ [c] "
false " [c] }"
)
which I've now converted (i.e. just switched namespaces, have not rewritten the structure) to fudje and am trying to run with kaocha. Do you really need to wrap every test like the above in a (deftest some-name-probably-the-same-as-the-description-in-the-string ...)to make kaocha reporting work propertly (i.e. the tests are run and failures detected even without deftest, but the reporter says WARNING: No tests were found... )?Is https://github.com/lambdaisland/kaocha-midje included as a dependency in the project? I assume this integration aims to run facts without wrapping them in deftest expressions, as it seems to define a midje test type Note: I havent used midje in a very long time and never tried the kaocha integration, but maybe this library will help.
The test is no longer using midje, it has been rewritten to fudje
...and kaocha, so midje is no longer in the dependency tree and neither is kaocha-midje
I saw a previous comment on this channel about needing the deftest, it just didn’t feel quite conclusive - figured somebody here might know
It does seem that if reporting is required then things have to be wrapped in a deftest... I get the impression that unless someone submits an update to the reporter code (or provides a detailed issue), the situation is unlike to change (as fudje is quite niche in Clojure) https://clojurians.slack.com/archives/CCY2V0U6A/p1585853559083500
can someone file an issue about this please? thanks
AFK - will file one once I’m back online
Since fudje is considered niche - is there something else that provides the tabular kind of data driven testing pattern? I’m not attached to fudje, just have a lot of data rows and find the format productive and clear
In a previous life I used to use spock, a groovy based testing framework with a similar pattern (yes, horror, non-functional language and curlies etc, but I found and still find the format very readable and productive):
Anyway - will file a ticket and keep looking for alternatives
Hmm perhaps clojure.test/are
I suggest clojure.test/are if you wish to express a table like collection of values to test. The next step up would be to use clojure.spec and generative testing, using the defined specs to generate a range of values to test with - some basic examples at https://practical.li/clojure/clojure-spec/generative-testing/ and https://blog.klipse.tech/clojure/2020/09/11/test-check-clj.html
fudje is niche-ish but we do want to support it. Since it's clojure.test compatible it wasn't clear if there was anything extra we needed to do. But if common usage patterns don't work well with kaocha then we can consider if we can handle those better
midje OTOH we have little interest in supporting better, it's just too weird and hard to integrate with, and fudje exists as a clear upgrade path