Agile Developer’s Toolbox: Coverlipse
For those who like juggling multiple tasks, Eclipse provides a great opportunity. Take developer testing for example. JUnit comes standard out of the box and the agile developer can literally start practicing Test Driven Development (TDD) right off the bat. As individual developers increase the number and detail of unit tests the team may want to know how much of the code base is actually being tested. This is where test coverage comes into the picture.
The agile teams practicing Continuous Integration gain insight of their test coverage through tools such as CruiseControl and Cobertura. Since test coverage reports are generated as part of the CI cycle, the latter two provide an aggregate view of the test coverage of the entire code base. The reports, while open to the entire team, are mostly analyzed by the architects or project managers who would like to gain insight of the team’s coverage and trends.
Individual developers working with Eclipse can also gain the same insight into their test coverage without having to commit changes and wait for the CI server to complete the build. Coverlipse is an Eclipse plugin designed to measure the test coverage of Java code. It’s fully integrated into the Eclipse environment and allows the agile developer to see which parts of the code are actually tested. The ability to see test coverage immediately provides the shortest path to knowing what each developer’s individual test coverage is, even before a single line of code is committed to the repository.
Quick Tutorial
-
Download and start Eclipse 3.2
-
Navigate to Help | Software Updates | Find and Install
-
Select Search for new features to install
-
Add a new remote site Coverlipse and point it to http://coverlipse.sf.net/update/
-
Finish the wizard and restart Eclipse
-
Create a new Java project
-
Add the following Java class:
public class NumberComparator { public NumberComparator() { super(); } public boolean isGreater(int pFirst, int pSecond) { if (pFirst > pSecond) { return true; } return false; } } -
Add the following JUnit test case:
import junit.framework.TestCase; public class NumberComparatorTest extends TestCase { public void testIsGreater() { NumberComparator nComp = new NumberComparator(); assertTrue(nComp.isGreater(5, 4)); } } -
In the Package Explorer, right-click on NumberComparatorTest and select Run As | JUnit w/ Coverlipse
-
Wait for the test to complete
-
Open the NumberComparator class. You should see the Coverlipse markers as in the following picture:

-
Notice the red mark on the left. This indicates that part of the method is not covered by the unit test.
-
Add a second assert to the JUnit test case as follows:
assertFalse(nComp.isGreater(5, 6)); -
Rerun JUnit w/ Coverlipse
-
Notice there are no red marks now as the entire code is covered

June 6th, 2007 at 8:44 am
I’ve been using EclEmma, although that does whole-line highlighting and I think I would prefer the display in the left side.
June 6th, 2007 at 4:27 pm
Hi Robert,
EclEmma is also a great tool, if not better than Coverlipse. I especially like its Coverage view where I think they did a great job of listing the Java classes and their respective coverages.
Both tools are great and I recommend them to developers who wish to gain some insight on their coverage. We all know that principles are what matters and tools are just vehicles to achieve them.
Thanks for the comment.
June 7th, 2007 at 11:22 am
I have found issues with the CoverClipse Plugin for Eclipse when unit testing classes with the JMock Framework. It took about a day to get my answer in the jmock forums and solve my perplexing problem (specifically, if you’re using jmock’s cglib extension jars(s) to mock concrete and abstract classes). So, just a word of caution when using JMock’s CGLIB libraries inside eclipse with Coverclipse enabled.
June 7th, 2007 at 2:59 pm
Michael, I am not aware of the particular problem, but like any other open source tool it’s not surprising to have a few glitches here and there. A separate issue with some of the plugins is the version incompatibility between the host Eclipse platform and the plugin itself. I found Eclipse 3.2 to be fairly stable and so far it seems to be supporting most of the plugins that I use quite nicely.
June 8th, 2007 at 11:19 am
Levant: Its true, most of the time there’s a smooth running (no conflicts) between plugins in the IDE and the actual dependencies used within a project structure viewed and manipulated in the same IDE (for example, maven project dependecies declared in the pom file, irrespective of scope). My particular experience was that the in-memory libraries loaded by Eclipse for the CoverClipse plugin were somehow interfering with JMock’s CGLIB libraries whenever unit tests requiring mock objects of abstract or concrete classes were run inside Eclipse. The tests were ok, but would not run at all (i’d find and paste the error, except its deep inside my email inbox)….but a simple flip of the switch in enabling/disabling the Coverclipse eclipse plugin would show a very perplexing and surprising effect. The tests would pass with the plugin DISABLED. Either one would run just fine, but not together. I couldn’t explain it, and neither could the guys in the jmock forums. I only happened to mention that i was using CoverClipse for code coverage and that sparked an investigation into the probable causes….and sure enough, that was the cause.