Thursday, March 13, 2008

Emma vs Cobertura

The 2 open source Java code coverage tools that are the best among the lot are cobertura and emma. Both have their own pros and cons.

Cobertura - http://cobertura.sourceforge.net/
vs
Emma - http://emma.sourceforge.net/

Points borrowed from: http://raibledesigns.com/rd/entry/emma_vs_cobertura_for_code
Video : http://video.google.com/videoplay?docid=820584080702226910

Emma:
1. Stats on both class and method coverage
2. Partial/fractional line coverages is unique trait - shown in yellow when there are multiple conditions in a conditional block like if (x < 0 and x > 10) and say x > 10 never gets executed this is shown in yellow. This is important feature which lets us determine if the tests cover all conditions of such more than one conditions conditional blocks.
3. Not being actively developed.
4. Stricter code coverage.
5. Integration with Eclipse available - http://www.eclemma.org/
6. Better documentation than cobertura.
7. Instrumentation process is faster than cobertura.
8. Standalone library and does not have any external dependencies.
9. Common public license 1.0 friendlier that GPL.

Cobertura: (since 2002)
1. GPL'd version of JCoverage (which is commercial). Project older than Emma.
2. Prettier reports.
3. Actively developed.
4. Branch/block and line coverages only - no class or method level coverage.
5. How many times a line has been executed - unique about cobertura.
6. <cobertura-check> where one can specify percentage of coverage that's a MUST or else build fails.
7. Data merge feature - good for QA labs... for merging coverage data to prepare historical trend graphs. Emma also supports it now but it seems its better with cobertura. Project long coverage collection possible.
8. Depends on other third party libraries.

Common factors in both of these code coverage tools:
1. bytecode instrumentation.
2. reports are filterable so you can tell what needs to be evaluated for code coverage.
3. offline instrumentation (most recommended approach) - separate instrument/execute/report tasks – this is what we adopted. The other approach is on-the-fly instrumentation.
4. ant integration.
5. testng integration.

The above information can be used in deciding about the right tool for your project. We went for Emma as it seemed to have good enough reports and was fast. I did not get a chance to experiment with Cobertura but will surely try it out soon.

4 comments:

Anonymous said...

nice summary....on one of our complex swing applications however...cobertura would hang ...whereas emma would hang in the "on the fly" instrumentation mode...it worked fine for the post compile - pre execution instrumentation. not as pretty in the reports, but all the info is there

Anonymous said...

By any chance did you try with Cobertura?

mind author said...

I think, cobertura still the best ..

Raji said...

1. First Download Cobertura 1.9.2 jar and put in your local file system and extract it.

1. Then create jars( lib, bridge, ejb ) for your project using Ant or eclipse.
2. Copy these src jars into your cobertura folder ( example : D:\Cobertura\cobertura-1.9.2\ )
3. Instrument the project jars using

1. cobertura-instrument.bat



2. All the project jars would now be instrumented with the cobertura code along with the creation of cobertura.ser file in the same directory.
3. Then deploy the jars in your development server.
4. You should also add the cobertura.jar in the classpath(BE,FE/IN depending on your project's nature).
5. Copy the cobertura.ser to the server and in the startManagedWebLogic.sh, add the below system property

4. -Dnet.sourceforge.cobertura.datafile=${directory where you have copied the cobertura.ser}/cobertura.ser



6. Fire your Selenium test cases either through Firefox(Selenium IDE) or using Selenium Remote Control. Or else run your application by manually
7. Shutdown the development server using WL Admin console and copy the cobertura.ser file back to the local cobertura folder.
8. Run the cobertura report using

5. cobertura-report.bat --destination

9. now you can check your local folder output folder Index.jsp