shakhal edited this page Sep 8, 2014 · 7 revisions


Where does the name "Cobertura" come from?

"Cobertura" is the Spanish and Portuguese word for "coverage." We were trying to avoid acronyms and coffee references. It's not too hard to associate the word "cobertura" with the word "coverage," and it even has a bit of a zesty kick to it!

Who started this project?

Cobertura is based on jcoverage, which was created by jcoverage ltd. Cobertura was started by Mark Doliner when he was an employee of SAS. SAS paid Mark to create the initial version of the project and get it off the ground.

Who works on this project?

Cobertura is currently developed by

  • Steven Christou

with help from other supporters of open source development.

You may also be interested on some facts about Cobertura analyzed by Ohloh See the COPYRIGHT file distributed with Cobertura for the full list of contributors.

Can I help?

Yes! Just check out the most recent code from our Git repository and start hacking. Some ideas on how to contribute are detailed on this page Please try to follow the same naming and coding conventions as the rest of Cobertura. To ensure same formatting, we use a Maven plugin which will format the files when code is built.

Who should I contact with questions?

Please use the cobertura-devel mailing list for all questions. This way the entire community can benefit from the answers.

Why should I use Cobertura instead of one of the other code coverage tools?

We think Cobertura produces the prettiest output. Pretty output means it's easy to read. Easy to read means you waste less time figuring out where to add test coverage. We also think Cobertura is easy to get running.

Why did you feel a need to fork jcoverage?

We felt it would be beneficial for the Java community if there were a Java coverage tool with a more open development process than jcoverage and Clover.

The GPL release of jcoverage had not been updated in about a year and a half. This in and of itself is ok, but the last release of jcoverage (1.0.5) has a bug which causes jcoverage to fail in Windows when used on a large number of classes (generally about two or three hundred). The bug is caused by the jcoverage ant tasks using a command line that is too large for Windows. A jcoverage user submitted a patch to the jcoverage bug tracker to fix the problem, but it was never officially released as a part of jcoverage/gpl.

Also, the version of BCEL distributed with jcoverage 1.0.5 causes problems when used with Java classes compiled with a 1.5 JDK.

What about Emma?

We haven't used it very much, but it looks like it does a pretty good job. Judging from the sample on the Emma web page, we think the Cobertura HTML reports are a bit easier to digest. It looks like Emma has some nice usability features, such as the ability to instrument all classes in a jar file with one command. A little friendly competition never hurt anyone.

What do I need to use Cobertura?

Cobertura should work on any platform with with Java 5 or newer. The Cobertura download packages include all the dependencies you'll need (ASM, log4j, etc.)

What is code complexity and why should I care about it?

McCabe's cyclomatic code complexity algorithm is used to determine how "complex" a given piece of code is. As code becomes more complex, it becomes more error prone. If a class has a high complexity number, then that class is a good target for additional test coverage.


When I generate coverage reports, why do they always show 100% coverage everywhere?

When I generate coverage reports, why do they always show 0% coverage everywhere?

Cobertura is probably using the wrong .ser file when generating the reports. When you instrument your classes, Cobertura generates a .ser file containing basic information about each class. As your tests run, Cobertura adds additional information to this same data file. If the instrumented classes can not find the data file when running then they will create a new one. It is important that you use the same cobertura.ser file when instrumenting, running, and generating reports.

The best way to do this is to specify the location of the data file when running your tests. You should pass the -Dnet.sourceforge.cobertura.datafile=${basedir}/cobertura.ser sysproperty to the JUnit task.

Another common problem is that the cobertura.ser file is deleted, but the previously instrumented classes are not also deleted. Any time you delete your coverage data file you should also deleted all instrumented classes.

Why is Cobertura causing me to have classpath conflicts with ASM?

Cobertura uses ASM to modify your bytecode. There are a few other popular programs that use ASM; Groovy and Hibernate, to name two. You could have problems if Cobertura uses a different version of asm and you add both versions to your classpath.

Cobertura only uses ASM when instrumenting. Cobertura does not need ASM in your classpath when running tests. If you're seeing classpath conflicts, just make sure the asm jar that comes with Cobertura is used only by Cobertura, and only when instrumenting.

Is it possible to graphically show my test coverage over time?

Yes, using QALab. From their website, QALab "allows developers, architects and project managers alike to be presented with a trend of the QA statistics of their project." Another great application is Sonar, a code inspection utility that generates reports over a period of time.

Using Cobertura with a Web Application

I have automated tests that use HttpUnit/HtmlUnit/Empirix/Rational Robot, can I use Cobertura?

Yes! The process is a bit more involved, but the concept is the same. First instrument your compiled classes. Then create your war file. Then deploy the war file into your application server (Tomcat, JBoss, WebLogic, WebSphere, etc). Now run your tests.

As your classes are accessed, they will create a "cobertura.ser" file on the disk. You may need to dig around a bit to find it. Cobertura puts this file in what it considers to be the current working directory. Typically this is the directory that the application server was started from (for example, C:\Tomcat\bin) Note: This file is not written to the disk until the application server exits. See below for how to work around this.

Now that you know where the cobertura.ser file is, you should modify your deploy step so that it moves the original cobertura.ser to the appropriate directory in your application server, and then moves it back when finished testing. Then run cobertura-report.

I'm using JBoss. When I stop the server, the coverage data file is not written. Or the coverage data file is 0 bytes. Or cobertura-report and cobertura-merge complain that the coverage data file is invalid (possibly throwing an EOFException).

Cobertura only writes the coverage data file at shutdown. It does this by adding a shutdown hook with Runtime.getRuntime().addShutdownHook(). JBoss has its own shutdown hook that calls System.halt() when its finished. If the JBoss shutdown hook finishes before the Cobertura shutdown hook, then the call to System.halt() causes the JVM to halt and the cobertura.ser file will be incomplete.

To fix this, set -Djboss.shutdown.forceHalt=false when starting JBoss.

Cobertura only writes the coverage data file when the application server shuts down. We do not want to stop our application server after running our tests.

It is possible to instruct Cobertura to write the data file. One of your classes should call the static method net.sourceforge.cobertura.coveragedata.ProjectData.saveGlobalProjectData(). For example, you could add something like this to a "logout" method in your web application:

try {
  String className = "net.sourceforge.cobertura.coveragedata.ProjectData";
  String methodName = "saveGlobalProjectData";
  Class saveClass = Class.forName(className);
  java.lang.reflect.Method saveMethod = saveClass.getDeclaredMethod(methodName, new Class[0]);
  saveMethod.invoke(null, new Object[0]);
} catch(Throwable t) {

We are looking for a better alternative to this. Feel free to send us your suggestions.

Cobertura Annotations

There have been several questions as to how the new cobertura annotations can be utilized by everyone. Here is a simple wiki page on how to implement this new feature. (Note: This feature is available in cobertura 2.0 and above).

ClassNotFoundException during instrumentation

A lot of people have encountered the following exception:

[cobertura-instrument] WARN instrumentClass, Unable to instrument file /tmp/mypackage/TestClass.class
[cobertura-instrument] java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.MainClass

This is because during instrumentation in cobertura 2.0, we use ASM to rebuild the .class files. We rebuild the stackmap which is a requirement to be compatible with java 7 and anything after. This does not mean that we recompile the code, however ASM requires that we provide the binaries of the other classes just in case it needs to look up any super methods. To fix this we use an argument called auxClasspath. This allows us to create a custom classloader and will use that along with the current classloader. So only items that need to be included in the auxclasspath are the classes that it can't find. This is similar to how findbugs auxclasspath works. Please see the references pages for how to use auxClasspath.