views:

1884

answers:

3
+1  A: 

Try adding cobertura as a compile scope reference. And post the relevant parts of your pom.

sal
Wouldn't having as a dependency (with compile scope) only be helpful if your project is somehow trying to build something on top of cobertura? This is probably not what Ajay was looking for.
James Kingsbery
+6  A: 

While I cannot find the exact page anymore, I recently read a discussion of why running the tests twice is considered a good idea. The key issues cited were around the effects of the Cobertura byte code alteration on the accuracy of your tests. In certain cases the timing of your code execution might be important, the byte code alteration can cause tests that fail in JUnit to pass when run only in Cobertura and vice versa. For this reason, it was recommended that the tests be allowed to execute twice. Most of the examples cited were around multi-threaded behaviors, but I imagine that there could be other cases were the byte code alteration can cause issues in your tests. Having the tests execute both ways provides you with baseline results and also reduces the chances of sending you on a wild goose chase if Cobertura is in fact altering test success.

DavidValeri
This is a great point. Another thing I ran into one time is that because of the byte-code re-writing, if your code uses reflection a lot, it can cause issues. For example, if you have a utility that extracts fields from a class, and your unit test asserts that an example class has three fields, this test will actually fail when you run it with code coverage.
James Kingsbery
+1  A: 

This happens because the reporting execution requires the test execution so it can create the reports. If there were a "site-only" goal on the site plugin that didn't have the @requiresDependencyResolution test annotation, it could be bound to the project's prepare-package phase and your reports would be generated without the tests running twice. Unfortunately there seems to currently be no such goal (see my question on the subject).

See my answer to the question for details of a workaround.

Rich Seller