You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a multi-module build we can have a situation where one module's tests exercise code paths of another module it depends on. If we're not careful, this could shadow uncovered code in the depended module, depending on the relative order of their tests in CI.
Let's say,
a depends on b;
we test a then b;
testing a exercises a code path in b which b does not exercise by itself;
coverage report for b will indicate that code path as covered.
If we're strict about the modules' interfaces, we'd want their coverage to be guaranteed by their own tests, not their dependents'.
Running rm b/target/scala-2.13/scoverage-data/scoverage.measurements* between test invocations seems to do the job, but I wondered if an Sbt Task wouldn't be more appropriate or even if there was a way to avoid writing those measurements to dependencies' $coverageDataDir in the first place.
Thank you
The text was updated successfully, but these errors were encountered:
Hi,
In a multi-module build we can have a situation where one module's tests exercise code paths of another module it depends on. If we're not careful, this could shadow uncovered code in the depended module, depending on the relative order of their tests in CI.
Let's say,
a
depends onb
;a
thenb
;a
exercises a code path inb
whichb
does not exercise by itself;b
will indicate that code path as covered.If we're strict about the modules' interfaces, we'd want their coverage to be guaranteed by their own tests, not their dependents'.
Running
rm b/target/scala-2.13/scoverage-data/scoverage.measurements*
between test invocations seems to do the job, but I wondered if an SbtTask
wouldn't be more appropriate or even if there was a way to avoid writing those measurements to dependencies'$coverageDataDir
in the first place.Thank you
The text was updated successfully, but these errors were encountered: