Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.5.1
-
Fix Version/s: None
-
Labels:None
-
Number of attachments :
Description
Invoking "clean verify" on the parent of a multi-module project has the effect that each module is built isolated from the others. As though the targets were invoked for the modules separately. However, I think in the context of coverage measurement the semantic should be different.
If the targets were invoked on the parent project, I think the coverage measurement should be done for all the modules together and result in an aggregated coverage report. Why else invoke the targets for the parent project ?
Important is that some modules might use each other's classes. Currently it looks like the shared classes have no coverage at all. While this is not the case. They're just not located in the same module being tested. (Because they were not instrumented ?)
An alternative would be to allow the users to specify dependencies to include in the coverage process. Whether it were a sibling module or not. Which is of course a recursive process because the included dependency might have cobertura configured to include other dependencies as well.
I have a similar situation that was not fulfilled by
MCOBERTURA-65, as James hinted that it was past the scope of that issue http://jira.codehaus.org/browse/MCOBERTURA-65?focusedCommentId=286002#comment-286002.I currently pull in abstract tests using <type>test-jar</type>, and they are not currently instrumented.
Currently this causes cobetura gives the impression that my code is not covered by the implementation of these abstract blackbox tests. Currently I simply extend the abstract test and pass it my implementation without reimplementing the tests themselves. Blackbox tests are more useful to me than whitebox tests because they enable me to split tests from their implementations completely. It is this complete separation that currently foils cobertura and emma.
We might extend the plugin to optionally provide the instrumented classes in a new jar artifact in a similar way to -tests.jar and -sources.jar, say -cobertura.jar. Then people could manually pull in these artifacts into their test scopes using <type>cobertura-jar</type> or <type>cobertura-test-jar</type>? This would require the instrumented classes to be put into the local repository, but they would be clearly delineated from the uninstrumented classes, so they would not interfere with people by default selecting <type>jar</type>. There may however be issues with people putting the <type>jar</type> libraries on the compile scope classpath alongside the instrumented classes, as the compile and runtime scopes overlap with the test scope.
I am not sure how the process would work internally, but there should be examples in maven-jar-plugin for how they handle exporting to -tests.jar. https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html You may even be able to reuse part of their mojo code to avoid reimplementing it.
I would be particularly interested to have my tests from dependent modules available this way. If it catches on we could eventually easily get reports for the degree to which we utilise upstream libraries as well as local modules!