As I mentioned in Migrating from Boot back to Leiningen, we have a setup with multiple builds (editor, eval_worker, renderer), and multiple “targets” (dev, test, prod).
So this means you get 3x3 separate build configurations. We have some code to generate these for us so we don’t have to maintain 9 different build configs. As people adopt ClojureScript more I think this will become more common, e.g. to have an admin-backend + a user facing frontend as separate builds, each with dev, test, prod.
It seems shadow-cljs has better support for this than the alternatives, with built-in dev and release modes, and with the ability to specify multiple builds, but what these do is (I think) hardcoded. E.g. we run our tests on node, so we’d like a :test target for each build that has :target :nodejs. Is that something that might be possible in the future? What would such a “matrix” setup look like?
I’m working on something related to tests currently.
I think that “tests” are standalone. They are not part of a build, they are their own build.
The test build then also has :dev and :release modes since :none is fine during testing but you also want to test :advanced. So you actually have 4 targets not 3.
I’ll have something to show for this soon, its a bit abstract currently as I’m not 100% sure where I’m going yet. It might not be feasible/desirable to to run everything from the CLI but instead actually let you configure if in shadow-cljs.edn with its own {:target :test}.
Testing usually involves actually running them and that must respect process exit codes and such so that CI can detect actual failures. The first version will probably be focused on compiling the tests and then at later date maybe some kind of pluggable “executor” mechanism to run test via karma or others.
I outlined what I think is a good approach for tests in the browser here.
The same can pretty much be done for running the tests in node.
Since I made the tests queryable at runtime (no macro) it should be much easier to write re-usable test runners.
Probably could add some easy hooks for karma or write another dedicated ns. :require for test namespaces is not necessary as they will all be included when matching the :ns-regexp "-test$". Can add many other filters if necessary. Live-reload will also work properly. It currently runs all the tests on reload but could be modified to run only reloaded tests.