running junits and cobertura with maven

2019-01-14 15:34发布

问题:

In our project, we run both junits and cobertura using maven. The problem I am facing is that,

  1. junit test cases are running twice, once before the jar creation process and then once again for generating cobertura coverage reports. When running cobertura and junits with ant, we run junits only once since, cobertura runs along with junits. Is there a way to configure the above case with maven. I know we can use "maven.test.skip" property to skip junits. But when I do this, I am not able to see junit xml & html file reports.
  2. Also, in maven how to configure junits to run in batch or parallel ?

thank you!

回答1:

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.



回答2:

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



回答3:

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.