Version française disponible

Improve your code coverage with Emma

In this new article, I introduce you the EclEmma plug-in (contraction of Eclipse & Emma), Emma is a free code coverage tool for the Java programming language. Of course, EclEmma is its porting under Eclipse.

I am using it since several weeks now and… I am wondering how I manage without it until now.

Plug-in installation

From your Eclipse menu, select Help -> Install New Software… -> Add site. The update site is http://update.eclemma.org/. To complete and finish the installation, Eclipse has to be restarted.

How to use this software ?

To run your unit-tests, you right-click on a package, a test suite or a test case, in the menu select Run As -> JUnit Test.

To run your test(s) with EclEmma in order to check the coverage rate, what you have to do is very similar. You only have to use the new submenu “Coverage As” instead of “Run As”. You can note that it is possible to use the coverage launcher button in the toolbar (Java perspective), but I’d prefer the menu.

Full presentation

Here is an example, step by step, to see how it is working. In the same time, we are going to talk about Test-driven Development.

So, we want to implement the following functionnality: the conversion of a raw text into a properly formated HTML text. The example will be based on the french language because we use much more special characters. This is a classical & easy stuff to do, but just perfect to present EclEmma.

Let’s start by writting our first test to manage the accents management (é, è, à, ù and so on) .

At this stage, the test is not compiling at all. Let’s implement just the code we need in order our test successfully compile.

After creating the “ConvertToHtml” class and its “convert” method, we can run the test.

Like we expected, test is failing.

Let’s implement the “convert” method.

Now, test is passing. Enjoy the green light!

But the implemented code is not perfect, it needs some refactoring.

Let’s check out if the test is still passing. Yes, it does.

At this point, you can wonder: Ok, I know that my code is enough to pass the test. But, how to be sure I haven’t written too much code. Some lines of code I have never tested in my test…

The solution is obviously EclEmma. So, we run the test using the coverage checker in EclEmma.

The covered code is highlighted in green. In this case, our code in fully tested.

Moreover, you can access to the coverage view. The coverage rate is 100%. Great !

I have to admit that, on this kind of example, this is not so difficult to get the highest rate. But, keep in mind, the usefulness of such tool when you are working on a big project whith several hundred thousand lines of code and thousand of tests.

For this online tutorial, I’m going to do some bad stuff and go against TDD principles. Let’s bring some modifications to the application code without having written a new test.

And rerun the test with EclEmma.

The coverage rate is now at 95%. EclEmma shows us that what we added is clearly a not-tested code. The corresponding lines of code are highlighted in red. Thanks to EclEmma, we get the feedback that the test is not complete.

After a glance at the coverage view, I know exactly which files are concerned. That’s not as funny as it has to be, because I have only two files in my project.

To continue the example, we can add a new test to test the successful no-conversion of a text which has not to be converted in HTML format.

I benefit from the time spent to think how to built my test to improve my code by deleting the prefix in the output text, and extract it as a constant.

I use EclEmma again and… We are back to a 100% coverage rate, all is successfully tested, and my code do exactly what I want (no more and no less).

Once again, and for teaching (of course), we modify the application code without modifying or creating a test. Now we suppose we use a no-conversion suffix and not only a prefix. We run tests again. Oh, nice colors !

A line of code is highlighted in yellow, it means this line is partly tested. We can arrange the code a bit to have a better understanding of this situation: let’s divide this line in two parts.

In fact, we go through the first part of the AND but not in the second one (Why ? Because the first part has returned false).

A line of code can get the following color code:

• Green: Line is fully covered, a test (at least) execute this line;
• Red: Line has not been executed at all, you have to write a new test;
• Yellow: Line is partly covered, it contains covered code and not-covered code. You can arrange code, like I did, to know which code you need to test.

EclEmma provides two different coverage rates, the one on the business code (this is the most important rate, the one which needs to be monitored and be improved), and also a rate on tests itselves. This one is also useful, because showing you the lines of code not executed in your tests. In other words, it helps you to refactor your tests.

Lastly, you can check out for other measures. For each Java element (Java project, source folder, package, type or method) EclEmma provides a Coverage property page summarizing all coverage counters. You can access to this page on the project properties. These figures can be useful for the developer, the project manager, or be part of a customer report.

I think EclEmma default configuration is good and enough. Nevertheless, you can modify some options such as the color highlighting or add the rate on each file in the package explorer view (see below).

Conclusion

According to me, EclEmma (Emma generally speaking) is an essential software every Java test-unit developers should have in their “toolbox”.

It will help you to reach a higher coverage rate (and thus, improve your software quality). Maybe one day, you will succeed in reaching a 100% coverage rate (but… Nothing is less certain, because the code is not as fully testable as we want it to be… this is another story… and especially a different topic).