Great post. I’ve used it and it works excellently. I adapted it using the maven antrun plugin so you can have everything in the parent pom file, optionally with external ant script files. Using the plugin you don’t need the cobertura installation and only need to run mvn twice and you have your report. If you’re interested in more details, let me know.
I’m having the problem of multi-module and test coverage. I read this post, but it works with cobertura plugin and in my project we don’t use this plugin. Could you please send me your pom without cobertura? is that has to do with the command run? Is it possible to run ant command with a project maven?
we are getting stuck in maven pom.xml to get coverage report if the test case are executing fine but data tables are not available now becasue they are old for some modules and we wont use further but it is affecting the overall coverage report
I could resolve all problems. The path of my cobertura.dir was wrong. Now, I have another problem. When I run report and want to see the result of the coverage, it appear all in red, 0% coverage over all class tested. What could be?
One reason may be that you have somehow failed to annotate the classes before executing the tests. Another may be that you haven’t combined the .ser files properly. I would double check the order the steps are executed in.
I am facing the same problem, like [taskdef] Could not load definitions from resource tasks.properties. It could not be found, and my build.xml is similar to the above and i just updated the path COBERTURA_HOME to be D:\cobertura-1.9.41
Can you please help me on this.
My suggestion if you want to run this using Jenkins is to create freestyle project. Check out the source and add four consecutive steps. First the Maven compile step, then the Ant instrument step, then the Maven test step and finally the Ant report step. The last thing you would like to do is to have Jenkins to display the result. You can add support for Cobertura reports at the end of the job configuration. I don’t remember the details and I don’t have a Jenkins that I could try with to get the commands correct. But Jenkins has a Cobertura plugin that you can use. I think it s a plugin at least, it could be built in as well.
Thanks for this interesting post. I’m wondering how surefire plugin knows about the generated .ser file in your example.
I tried to pass it via system.properties.variable or -D option but it seems it doesn’t work.
Tests are executed against instrumented libraries but .ser file is not updated.
If I run unit tests with ant and by providing the .ser it works fine.
THANK YOU for posting this solution. I spent a day looking for a solution, many of which are either out of date or simple don’t work. My frustration has ended with your post. It was easy to read and easy to understand and I don’t even know how to use Ant, but picked up on it quickly.
Thanks for the nice post. I found this article very helpful as I am using a separate module for testing. The report is working fine except for a small issue – unable to locate the source code. I am using the ANT script as-is and run from the root. Would you be able to help with this?
It is very hard to know what is causing your problem. I would assume that you need to change something in the Ant script but i am not certain what you should change. I would double check the paths in the Ant script.
So, sorry. No I can’t say what is wrong without running on your system. And I can’t do that.
I haven’t checked if any change in Maven has made it possible to do this with a pure Maven solution.
But I kind of doubt it. The problem is that Maven uses depth first when it builds a multi module project. Each module is built completely before it starts with next module. Instrumenting the classes is done before the tests are executed. But the classes in an earlier module will not be touched again once the module is built and especially will they not be instrumented. Therefore, a pure Maven solution is not possible.
The better solution? Keep your unit tests within the same module and make sure the test coverage is relevant using unit tests.
I haven’t tried to use any code coverage tools using Gradle. Cobertura has to annotate the classes that should be executed before the tests are run. The coverage will then be recorded and you can see stats.
That said, the symptom you report sounds to me as if the production classes haven’t been properly annotated before the tests was executed.