WIP: To triage issues that people have with clojure.test with the goal of finding areas where it could potentially be improved.
Constraints: Retain backwards compatibility with existing callers.
Some slack conversations on the topic:
Just for easy lookup, here are all the open issues: JIRA open issues, labeled clojure.test
thrown?test doesn't attempt to unwrap exceptions. It should probably test the main exception type and, in some situations, test the cause type as well (for
ExceptionInfo– maybe others?). See https://dev.clojure.org/jira/browse/CLJ-2458
are can be awkward at times, e.g. sometimes you want to put an
(is ,,,, msg) inside it for more control, e.g. of the message — which leads to the reporting of the error twice because are also wraps an
is over your form.
areprovide basic equality/truthiness checks, and there are simple assertions around exceptions, but nothing to help with assertions about more complex data structures without very verbose code (see, for example, Expectations'
test-varslets you run a single test, it provides no success/failure feedback and requires
Vars rather than just symbols – https://dev.clojure.org/jira/browse/CLJ-1908 would address this.
Problems people have in structuring tests, test suites etc. How to map ns's and functions to test ns's and functions? 1-1 mapping, 1-many mapping etc?
Is this even a good idea? If not do clojure.spec property based tests also need a test runner? Perhaps other projects such as leiningen need to plug a gap here?
Alex Miller mentioned there was a possibility of splitting clojure.test out as an external dependency from clojure.core so it can evolve at its own pace.
This (incomplete) list is provided purely for information, as possible sources of inspiration for changes that could be made or pain points that people have (that have already turned into a library):