Fork me on GitHub

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

đź‘€ 1

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)


poly ws returns a lot of information about the current state of the workspace. Maybe it could be useful?


@U2BDZ9JG3 it looks like :paths is promising but it doesn't include projects? Are the keys documented somewhere? I don't understand the distinction between existing/missing/on-disk


FYI, I managed to list all dirs with

clojure -M:poly ws get:paths color-mode:none
(Note: the color-mode:none to prevent color codes)


FYI, full clj-kondo oneliner (requires bb):

clj-kondo --lint "$(clojure -M:poly ws get:paths color-mode:none | bb -e '(-> (:existing *input*) (->> (clojure.string/join \:)))')"

polylith 1

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 and feel free to contribute with your ideas.


It doesn't seem to use Cognitect's test-runner -- it uses the built-in clojure.test/run-tests function.


It used to do that but we must have changed it at some point. Thanks for pointing it out!


FYI, full clj-kondo oneliner (requires bb):

clj-kondo --lint "$(clojure -M:poly ws get:paths color-mode:none | bb -e '(-> (:existing *input*) (->> (clojure.string/join \:)))')"

polylith 1