Coverlipse FAQ

My test run finishes but I don't see any results!

This can have a number of reasons:

• Problem: Probably, your packages are ignored filtered permanently or by your launch target only. Solution: Check the package filters in the launch target. Especially, check the package invariants.
• Problem: In versions earlier than 0.9.5, this behaviour could happen if there was an error in the evaluation. This may be the case if there is no further processor activity after the test run. Solution: Upgrade to 0.9.5 or newer.

Is there a way to exclude (getter and setter) methods from the evaluation?

There is no way to explicitly exclude specific code from evaluation. However, Steven Grimm wrote a class that automatically tests getters and setters. Testing code is better than ignoring untested code!

Does Coverlipse provide an update site?

Yes. It's located at http://coverlipse.sf.net/update

java.lang.Class.getPackage() returns null when running a test with Coverlipse. Normal JUnit tests work fine.

This is the contract of java.lang.Class.getPackage(): "Null is returned if no package object was created by the class loader of this class." Thanks to Sun for that.
Here's the workaround code: Instead of SomeClass.getPackage().getName() use getpkg(SomeClass) where getpkg is as follows: public static String getpkg(Class cl){ String clname = cl.getName(); int lastDot = clname.lastIndexOf('.'); return clname.substring(0,lastDot); } This workaround was suggested by Robert Herrmann.

I'm getting an error saying: Plug-in de.uka.ipd.coverage was unable to load class de.uka.ipd.coverage.plugin.launcher.CoverageLaunchConfigurationDelegate

This happens with Eclipse 3.0 when trying to launch a Coverlipse launch target before executing any other Coverlipse code.
This error can be prevented by executing any other Coverlipse action before executing the launch target, like showing a view or showing the launch target in the launch target management area.

Can I use Coverlipse on a project that uses Java Commons Logging?

Short answer: yes, since version 0.9.3.
Long answer: Java Commons Logging introduces a classloader hell that is discussed to some extend by the author of Log4J here and here.
Thus, Coverlipse adds the Java Commons Logging package to those handled by the system classloader. This way, projects that use Java Commons Logging can be tested with Coverlipse. However, it is not possible to test the Java Commons Logging itself with coverage by Coverlipse.

Assertions don't seem to be executed, even when enabled.

Again, this is a problem occurring only with Eclipse 3.0. Because of a Bug in the used Eclipse 3.0 API, VM Arguments are not regarded with this version. There is no known workaround.
This problem does not occur with Eclipse 3.1

I have found a bug. What should I do?

Go to the Bugs page at Sourceforge and check if your bug already has been reported. If not, submit a new bug report or post the issue in the forum.
The most important thing about a bug report is a description that allows the reproduction of the ill behaviour. So, if your bug is about the interaction in Eclipse, please describe what you are doing, expecting and what Coverlipse does instead.
If your bug is about a JUnit test that fails where it shouldn't, please include at least a stack trace. In most cases this is not enough to reproduce the bug, so expect to be asked about example code. The best example code is a small Eclipse project with a class and a test that produces the ill behaviour.
In all cases, make sure to include the version of Coverlipse and Eclipse you are using.
Please do not report problems which are obviously due to classloader problems. Those won't be fixed individually and will get a general solution with the classloader independent mode.

How can I contact you?

You mean, besides the email address at the bottom of each page of the homepage, the Sourceforge email address, and the forum?
You could join #coverlipse at FreeNode. I'm online there with the name arwate, when I'm online.

What code coverages does Coverlipse support?

For now, Coverlipse supports Block Coverage and All Uses Coverage. Branch coverage is planned to come with Version 1.0.

Does Coverlipse support Java 5?

Yes, Coverlipse can also test Java 5 programs.

There are coverage tools a dime a dozen, even free ones. What makes Coverlipse unique?

For one, it is an Eclipse plugin. It does not provide several hundred ways of configurations like other coverage tools, it just uses the Eclipse way of configuring JUnit tests and gives you direct feedback in the Java Editor and specialized views.
Second, it can give you the data flow analysis All Uses Coverage. To my knowledge there is no other tool that can do data flow analysis on Unit Tests for the Java language.

Where can I get the source code?

The source code is in the Sourceforge CVS. Instructions how to access it are available here.

How can I build Coverlipse myself from the CVS?

• In Eclipse, add a new CVS location:
• host: cvs.sf.net
• repository path: /cvsroot/coverlipse
• user: Anonymous
• connection type: pserver
• Check out the project coverlipse-tool from HEAD.
• Select File, Export..., Deployable plugins and fragments. Click Next.
• In the following window, select de.uka.ipd.coverage from the available Plugins, choose a zip filename as export destination and make sure the compiler and source compatibility is Java 1.4.
• Click Finish and wait for the zip file to be build. Install as usual.

Be aware that between releases the CVS content is unstable most of the time.

How much does Coverlipse cost?

Nothing. It's open source! Namely, its distributed under the Common Public Licence (CPL), thus you have the source code and you can modify the source code and you can redistribute your modifications under the CPL.

How does Coverlipse work?

Coverlipse uses the Apache BCEL toolkit to modify the Java Bytecode. During the test, all paths through a method are recorded on basic block granularity. After the test, the selected code coverage is computed and shown to the user.