0
votes

We do a bunch of automated testing against a fully deployed Java web application (in addition to unit testing) and would like track code coverage of these tests. The app is written in Java and runs on Tomcat. We currently use Cobertura to track coverage for our unit tests so I’d like to stick with Cobertura. I’ve instrumented our war and am able to generate reports from the coberura.ser file but it always show 0% coverage.

Here are the steps I’m following:

  1. Build the jar and war in the normal process (no instrumenting). Our application classes are packaged into a jar file which is then placed in the lib director of the war that we deploy.
  2. Unpack both the jar and war
  3. Rebuild again but this time instrument the classes.
  4. Copy the instrumented classes in to the unpacked jar directory. I’m doing this because instrumenting does not seem to output class files for things that do not have runnable code (like interfaces).
  5. Build the jar from the unpacked jar directory
  6. Add the new instrumented jar and the cobertura.jar to the lib directory of the unpacked war directory and build a war from that.
  7. Add the new instrumented war and coberturaFlush.war to the tomcat webapps directory
  8. Add cobertura.ser (that was generated during instrumentation) to tomcat bin directory
  9. Start Tomcat
  10. Do stuff in the app
  11. Hit /coberturaFlush/flushCobertura in a browser.
  12. Stop Tomcat
  13. Use cobertura-report.bat to generate the report from the cobertura.ser file

Here's what I've tried thus far:

  • I confirmed the class files in the jar have references to cobertura so I’m confident that they are instrumented.
  • I’m using coberturaFlush.war because I’m getting a bunch of NoClassDefFound errors when I stop the app so it doesn’t look like the shutdown hook is working correctly. This seems to be a common issue and coberturaFlush seems like a reasonable workaround.
  • I’m confident Cobertura is using the correct .ser file. When Tomcat starts I see some that file quickly go down to 0KB and a cobertura.ser.lock file created and then in goes back to the original size and the lock file is deleted. I see the same thing happen when I call flushCobertura as well as when I shut down Tomcat.
  • I’ve also tried generating reports with the .ser file after I call flush but before I stop Tomcat and that did not work either.

Am I missing something? Any idea why Cobertura always says 0% coverage?

Thanks in advance.

1

1 Answers

0
votes

I think you may be in "JAR hell". I was having the same problem, and was able to get around it by:

  1. Do not include the cobertura.jar file in the webapp environment
  2. Do copy the cobertura.jar file to the Tomcat common library directory

coberturaFlush is looking for the lib at the Tomcat level; by having another instance inside the web app, the counters for the webapp are separate from the overall Tomcat counters.

Another alternative, not the best but it works, is to have your webapp call the saveGlobalProjectData method as outlined in the Cobertura FAQ. Both methods worked for me, but since I didn't want to add any special code to my app, I chose the first.