Cobertura a coverage tool. A coverage tool shows how many lines of code
are touched. In most cases you’ll use Cobertura to see how good your
regressions test are. You can also use it to see how many lines of code
are reached or to improve code that is accessed a lot.
will generate HTML or XML reports. Cobertura is meant to be used with
ant, but it also works with the command line and plugins are under
developement for Maven2 and Eclipse
This article will explain how to interpret the generated reports and how to use Cobertura in your projects.
Let’s start with a test report and see what’s in it. A test report looks like this:
first column shows the package name, the second column how many classes
there are in the package. The third column is named Line coverage. Line
coverage is the amount of (useful) lines of code that are executed. A
useful line is a line of code where something happens (so no curly
braces or newlines).
The next column gives us information about
the branch coverage. Branch coverage is the coverage of the decision
points in your class (this can be a if/then/else loop. When your code
only reaches the first part of the if-loop and skips the else part
you’ll have 50% branch coverage). You’re probably thinking you’ll never
get a higher coverage than 50% with if/then/else loops. With Cobertura
it is possible to execute your code as many times as you want to test
all the branches you have.
The last column is the so called
McCabe cyclomatic code complexity. This is a way to determine how
complex your code is. One of the methods McCabe uses is measuring the
amount of decision points in your code. A higher rating means more
A high coverage does not mean that your
code is free of bugs! It is very easy to write code that touches many
lines but doesn’t really do anything. Always keep in mind to write
useful tests and then Cobertura will be a useful tool.
code example shows the second part of the report. The numbers next to
the line numbers tell us how many times this line is exected. The lines
without a number are the so called ‘not useful’ lines I mentioned
earlier. When the line is colored red it means that this line is never
executed. In the example above this isn’t a bad thing because when this
exception is thrown it probably isn’t a fault in the java code.
can use this overview for two purposes. One is check lines that are
called many times. If you try to improve the effiencey of these lines
you will improve the efficience of your whole application. The othe
purpose is checking the coverage of your tests. If some parts of your
code are never reached you might want to consider writing a test for it.
In the following examples I assume you’re using the directory structure of a Maven2 project and exectute all the commands in the root directory of your project.
let Cobertura to see your compiled classes you have to instrument them.
Instrumenting is done by executing the following command: cobertura-instrument target/classes/.
is possible to include more directories, some people think it is useful
to include unit test files. Jar’s can also be included.
Instrumenting the classes is nothing more than manipulating the java byte code (with ASM).
On every line of java code there are 3 lines added to the existing
classes to count things for your report. To communicate with Cobertura
the cobertura.jar file must be on your classpath.
Now it is time
to execute your classes. It usually means running all your JUnit tests,
but it basically can be anything (TestNG, no framework, etc.). When
you’re classes are instrumented right you will see a message like
“Cobertura: Loaded information on 39 classes.”
a datafile (default is cobertura.ser) to generate the report. The .ser
file is generated after instrumenting the classes and modified after
executing the classes. (Note that the datafile parameter only defines
the location of the first .ser file). While executing the classes the
.ser file will end up in the directory where the classes are executed
(in Tomcat this is the /jakarta-tomcat-5.5.12/bin directory, with
maven2 it is the directory where the pom.xml is)
If you notice strange behaviour check your (sub)directories for .ser files (they should all be removed)
forget to recompile your classes when you’re finished with Cobertura or
else Cobertura will be executed every time. It is possible to output
the instrumented classes to a user defined directory, but this is not
really handy with Maven. If you’re using Ant and JUnit it is done
automatically for you.
It is also possible to instrument the
classes of a webapp. The first problem you’ll encounter is that the
.ser file is not updated. This is done when you exit the servlet
container. Testing your webapp is useful to detect unused code or lines
that are executed many times. It is possible to write the .ser file
during executing, visit the Cobertura site for more information.
We’re not finished yet. The report has to be generated. Execute the following command to generate a report:
cobertura-report –format html –destination c:\temp\cobertura –source src\main\java
Now there should be a nice site in c:\temp\cobertura
It is possible to include multiple source directories. You can do this by adding â€“-source link\to\dir to the existing command.
Cobertura is a very nice tool that really helped me improve the quality of my code. It is nice to see the green bars grow .
I really look forward to the Maven2 and Eclipse plugin. But for now
this short list of commands will do the trick for any Maven2 project:
- del *.ser
- mvn clean
- mvn test
- cobertura-instrument target\classes\.
- mvn test
- cobertura-report –format html –destination c:\temp\cobertura –source src\main\java
- mvn clean