When I wrote this post about checking code coverage while testing Java applications, I got feedback from users who complained about the cobertura plugin running twice when run with the check goal.
Looking closer, I realized that this is indeed so.The tests are run once with the classes of the project and a second time with the instrumented classes.
So I did some digging and found out that the cobertura maven plugin spawns a separate lifecycle (called cobertura), that does the following, among other things:
- Bind the instrument goal to the process-classes phase
- Interject the instrumented classes on the test classpath in the test phase.
If tests are enabled (skipTests=false, or maven.test.skip=false) and the check goal is run, the tests run once using testClasses and then again, using ${project.build.directory}/generated-classes/cobertura which are the classes that are generated by instrumentation.
However, if tests are disabled (skipTests=true or maven.test.skip=true), the check goal does not run the tests at all because the cobertura lifecycle piggybacks off of the test phase that has tests turned off! This returns a 0% coverage for the check goal because the instrumented classes were never used!
To me, this looks like a bug. I reported this to the development team of the plugin but got an ambivalent response mostly to the tune of “I am no longer active on this project, ask the dev mailing list”. I did, but nothing came of it.
So here’s a simple solution for this problem. Force tests to run in the custom lifecycle and make it independent of the setting in the user’s pom.
I have created this plugin and bumped up the bug version from 2.4 to 2.4.1.
It can be downloaded from here.
Here’s the patch file relative to the source of the plugin v2.4.
I have tested it to the best of my ability and it works great!
${project.build.directory}/generated-classes/cobertura