I've seen a few discussions around the test runner, but I couldn't find an answer on how to test code coverage. In our current monolith we have a CI job that runs the tests with the cloverage test runner for that. Any recommendations on the approach? I was thinking that with the partial tests polylith does, measuring coverage on every PR will give odd results. So my best guess is that a regular test run on the whole repo with the cloverage test runner would be the way to go?

There was a convos some time ago about running clj-kondo: clojure -M:lint --lint ./bases --lint ./components --lint ./projects works like a charm How does one run Eastwood over a polylith repo? I get loads of linting issues because of the directory structure of that sort:

Directory: /home/yenda/splash-backend/bases
    File                   : api/src/splash/api/mutations.clj
    has namespace          : splash.api.mutations
    should have namespace  : api.src.splash.api.mutations
    or should be in file(s): splash/api/mutations.clj
                             splash/api/mutations.cljc

Perhaps the poly tool could return a list of source directories? So that it can be composed with other commands, Unix style Arbitrarily many tools can need this information (e.g. tools.namespace, refactor-nrepl come to mind)

Currently, poly test does three main things: 1) figures out the right classpath for running a specific project's tests (including the dev project) and then creates an isolated classloader based on that classpath, 2) figures out which bricks actually need to be tested based on what has been updated and the options passed in, 3) runs clojure.test/run-tests on the namespaces associated with those bricks. If there was a way to provide an alternative test runner function at that point, you could probably hook into coverage there?

I have some ideas around testing but haven’t fully sketched it out yet. You can have a look at https://github.com/polyfy/polylith/issues/126#issuecomment-917406360 and feel free to contribute with your ideas.