Not sure where the right place for such a discussion is, but is anyone using with-test or set-test?
What are your thoughts on attaching test cases to functions, executing them and rendering them as part of doc(s)?
Yes, this is Unison envy
I'd say #clojure is still the most relevant place. Also, an old somewhat relevant discussion: https://clojurians.slack.com/archives/C03RZGPG3/p1650317272864349 I'm still using that approach.
huh, I even liked your comment in the thread
the library metazoa also does something similar. I think the gap here exists in integration with other tools (e.g. clerk/kindly, test runners, etc)
i added support for metadata defined tests on vars in #lazytest but find that i still define tests in general in test files.
Part of the problem is that most test frameworks do not look at source folders by default, so tests attached to functions are ignored by default.
what would be the config necessary for the core clojure.test and kaocha? (i actually don't know of any other testing frameworks beyond those and @nbtheduke's)
to make them search other directories? either change the default in the code or pass in the appropriate flag at the cli
(looking now, might be a little more complicated if the test-runner is looking for a filename/ns pattern, it looks like kaocha looks at ns-patterns like "-test")
s/clojure.test/Cognitect's test-runner/ 🙂
You can specify directories to search for namespaces that contain tests. The default is "test" but you can add "src".
And, yes, you may need to override the default pattern match on files/nses -- depends on the test runner.
I wrote about this in the Expectations docs https://cljdoc.org/d/com.github.seancorfield/expectations/2.2.214/doc/getting-started#test-placement
(I didn't cover Kaocha there, but it talks about lein test and the Cognitect test-runner)
I think most code that uses a function doesn't actually care about loading/requiring the test for that function so there's some performance implications. > rendering them as part of doc(s)? I would make a distinction between tests and examples. I love the idea of making this data available to IDEs, but it should probably be optional.
I did play with Unison forever ago, and there definitely is something to having a function co-located with its tests, which is just very nice and self-contained/complete. I also do think that significance is much greater in non-REPLy/non-dynamic languages