For those that are not familiar with Sonar, ( I hope this post will make you at least try it or see it in action at http://nemo.sonarsource.org ) you can take a look at an earlier post I’ve written some time ago. In one sentence Sonar is an open source platform that allows you to track and improve the quality of your source code. One of the key aspects when talking about software quality is the test coverage or code coverage which is how much of your source code is tested by Unit tests. Sonar integrates with the most popular open source code coverage tools ( JaCoCo, Cobetura, Emma ) and the well-known commercial Clover by Attlassian. By default it uses the JaCoCo (Java Code Coverage) engine and you’ll shortly find out why 🙂
Before we move on, I’d like to give many kudos to Evgeny Mandrikov. This article is inspired by one of his older posts and its intention is to present a more updated comparison of the supported code coverage tools by Sonar and point out some differences regarding their results and the way they work. Recently Sonar changed its default code coverage tool to JaCoCo and this post tries to explain the reasons behind that decision. Some of the information is borrowed by Evgeny’s post and the image is also taken from Evgeny’s presentation about JaCoCo. So thanks a lot Evgeny!
Now let’s go to the meat. For the comparison you’ll see, I’ve used the latest available Sonar version 3.3, Maven 2.2.1, Java 1.6 and all analysis launched in a Windows 7 machine (Intel Core i3-2120 CPU @ 3.30GHz) with 8GB RAM. The projects were carefully selected ( a small, medium-sized and a large one – not that large as Java code base but large enough to extract some results ). I ran five analysis for each open source code coverage tool ( I excluded the commercial Clover from my comparison version ) and another five by disabling the code coverage mechanism. So that’s a total of 60 analysis ). In the following tables you can find some information about the code coverage tools and some basic metrics about the selected projects. Pay attention to the date of the latest stable release. Emma hasn’t been updated since dinosaurs era and cobertura is almost three years inactive. One might think that this isn’t an issue if they are stable and don’t need any new release. Well, the truth is that both of them have bugs that frustrate end-users and there’s no one to fix them. On the other hand JaCoCo is continuously evolving and improving…
The results of the analysis are displayed next. Some important notices. Emma doesn’t support Branch coverage that’s why you’re not seeing any metrics. Furthermore there are differences in the results of Line and Branch coverage, which are more concrete for larger projects. For instance in Sonar Jira plugin all three tools produce the same results whereas in Sonar analysis and Commons Lang projects you can see that the numbers are not the same.
Now take a look at a graph that illustrates in a more readable way which tool is the fastest.
It seems that Emma and JaCoCo need the same amount of time to compute their metrics… but… as we already mentioned there’s a huge difference. There’s no branch coverage in Emma reports. Cobertura is always slower than JaCoCo so again the winner is JaCoCo. Of course you can get even faster results by running a Sonar analysis without computing code coverage metrics 🙂
One last thing: JaCoCo, as the following figure shows is the only tool that analyses bytecode on-the-fly which is more . Cobertura and Emma run an offline analysis and use a class loader whereas JaCoCo has its own java agent for analysis code. This configuration allows JaCoCo to be very flexible, possible integrated with many other tools and frameworks and can be used with any language in a JVM environment.
So, to sum up, if you’re using Sonar ( if you don’t , you SHOULD ), then it strongly advisable to keep the default code coverage engine ( JaCoCo) , unless you have really important reasons for that.
Finally don’t forge to check Sonar’s Community 2013 unofficial survey and the upcoming book about Sonar by Manning Publications. The release date is in about 3-4 months but you can get an early access version here.
As always, feel free to comment or suggest improvements about the article and its content.