Clojurians Log v2
clojure
I’ve touched on this question in a thread recently as a tangent. asking here for a more thorough treatment. I’d like to get an idea of the code coverage of the test suite for my project. What do I mean by that? I’d like to run the full test suite and thereafter have some sort of report of which lines of code were touched and which lines were not. Hopefully a report on the clojure code rather than the underlying java code. I’d love to hear the advice of anyone who has done this.
@jumar, that’s an interesting idea… to see how much the code your changed in a PR is covered by tests.
Yes, quirky, I agree. Is cloverage something people are interested in improving. or is it pretty static? Some of my code which works fine in clojure triggers a TimSort java error in cloverage
Execution error (ClassCastException) at java.util.TimSort/countRunAndMakeAscending (TimSort.java:355).
class clojure.lang.Cons cannot be cast to class java.lang.Comparable (clojure.lang.Cons is in unnamed module of loader 'app'; java.lang.Comparable is in module java.base of loader 'bootstrap')most curious
oops. turns out lein test finds the same TimeSort error. OK, probably my fault. need to investigate
is the idea that running cloverage will automatically run a wrapped version of lein test?
I sort of see that implied by the github readme, but it’s not stated explicitly, curiously.
it seems the parser cloverage is using is not the same parser as in standard clojure. could this be the case? I have some code preceeded by #_ which is treated differently by cloverage vs standard clojure.
#_(dsdefn f
([[a b] c d] 12)q
([a [b c] d] 13)
([a b [^Ratio c d]] 14)q
([a b [^(satisfies int?) c d]] 15)
([a b [^Number c d]] 16)
([a b [^Double c d]] 17))[a b [^(satisfies int?) c d]] in the above example, but cloverage complains and exits.perhaps it is trying to intrument the code before ignoring it. i.e. instrument before interpreting #_ ?
hey! that’s cool
If you are still exploring there is also https://github.com/flow-storm/clofidence
cloverage has a number of weird "holes" and bugs, and doesn't work well with large codebases (or even large functions, I think?). I had to give up trying to use it at work. I haven't tried clofidence yet.
I gave clofidence a whirl on etaoin. It is different from cloverage in that it doesn't preserve the original source code format, but it gave me a good enough idea of what was covered.
We use cloverage on a fairly large codebase at work. It has some quirks but it works reasonably well for us We run it via GitHub actions, even on PRs - to see how much of the changed code is covered by tests.