David R. MacIver's Blog
Reusing Java's tools: Cobertura and Scala
I’ve recently been writing some collection implementations for Scala which will hopefully go in the standard library in the upcoming release. Naturally I want to make sure that I tested the hell out of them, so I’ve been writing a reasonably large number of ScalaCheck tests to test the code and make sure it does what I want it to. Earlier I realised I should probably be doing some sort of coverage checking to make sure I had tested things adequately so thought I’d see how easy it would be to plug Cobertura into a Scala project. And I have good news! The answer is: Essentially trivial.
There were a few minor issues that cropped up while doing it:
- Cobertura strips scala specific metadata out of the class files. This means that you must compile everything first, including your unit tests, before instrumenting code.
- Scala does a lot of name mangling and generates a lot of classes with weird names. Cobertura naturally doesn’t understand the mapping back to Scala code, so you’ll see the mangled names. They’re not usually that hard to figure out.
- Cobertura won’t be able to find your source files if you don’t follow Java directory conventions for packages.
Other than that, it all works fine. You get per line coverage information for your source files, decent per package and per class reports, etc. No problem.
Unfortunately my coverage wasn’t nearly as good as I hoped, so I’ll probably have to write a bunch more tests before I submit a patch.
Update: Actually, the line number reporting for Cobertura + Scala appears to be really bad, and often really hard to decipher. But it’s still a nice tool, and actually helped me catch some bugs.
Comments
Sanket on 2010-03-22 19:22:15:
Hi David,
This might seem to be odd... but can you comment on present pluggability of Cobertura in Scala. What do you think are the odds that integration of Cobertura( maybe modified to suite scala ) into scala would be encouraged by the community ?