sometimes nothin' can be a real cool hand

« Angry Fruit Salad | Main | CI Demo Part 4 - A new start »

Code Coverage by EMMA

Listen to this article Listen to this article

I've had some pain in recent times trying to get code coverage reports working on my project. Some of it has been shared with Steve and Jon who have both been helpful, but unfortunately I could never quite get what I wanted to work.

The source of my pain comes from the complexity of my build process. I have two web applications being built, and they each use some code from a shared code base. Lets call the web-apps foo and bar, and the shared code base baz. Both foo and bar have some unit tests and some in-container tests. baz has only unit tests, but just to add a bit more complexity, we use a byte-code enhancing tool on some of its classes to help with our app.

Ok - now for me to get a test coverage report for foo as a whole, I have to get coverage results from foo's unit tests, foo's in-container tests and baz's unit tests. Then I have to merge them all together and generate a report. The same model has to be repeated with bar

When I started, there was two main Java code-coverage tools on the market - Clover and JCoverage. They both work in very similar ways. First, they enhance the byte-code of your classes. Then you run your unit tests, which causes a file with coverage information to be written to disk. Finally, you run a report tool which reads that information and generates a nice report for you.

Let the pain begin... JCoverage started out ok. It enhanced my classes by just being told where to find the class files on disk. The unit tests ran ok for foo and baz, as did the in-container tests. But the merge blew up. I dunno why, but it did.

Next stop is Clover. I didn't get very far at all this time. Clover enhances class files in your Ant build by hooking into the compile task and making changes as the byte code is originally created. The problem is, our own byte-code enhancing tool gets confused when it looks at Clover-enhanced classes. So I was stuck before I even began.

We had planned some time just this week to try to resolve some of these problems, but before we began I stumbled across a reference to EMMA. Its only just been released, but is making some strong claims about competing with Clover in its descriptions. The documentation looked fairly complete, so I gave it a go.

Everything just works. Fantastic! The byte-code enhancing is similar to JCoverage (just point it at your classes). The merge tool had no problems dealing with results from three different runs, and in fact I don't even need to use it. The report target can deal with multiple input files. Merging is really just for compressing results into a single file. The report is not as sexy as JCoverage or Clover, but I only really needed the numbers anyway.

So next time you're looking for some coverage results, give EMMA a go. It oozed goodness for me...

Comments

I've been meaning to look at emma. Glad to see it worked out for you.

Thanks for that Marty. I can now cross EMMA off my list of things to look at. I saw it in a blog post a couple of days ago and bookmarked it, but had no real impetus to have a look.

I think that, technically, Clover actually does source enhancement. It takes the source input, then modifies it and compiles it. Of course, you had some good reason for using EMMA, i.e. the other tools didn't work, but I can't see any compelling reason to switch from Clover on an already set up project. The report-sexiness of Clover is a big plus I think.

I think you are right about the source enhancement thing Scot, but of course that was a moot point for me. I agree with you about (not) switching too. I've used both Clover and JCoverage in the past with success, and they were perfectly satisfactory.

There are several reasons for considering a switch to EMMA:

- it is free for *all* kinds of use and has a very permissive license
- it is fast and scales to thousands of classes
- it has an on-the-fly mode whereby there is no upfront instrumentation phase at all (source or byte code)
- it reports fractional line coverage, whereby other tools cheat and report full line coverage
- it can process classes and jars in-place, which users find convenient in practice

Post a comment