The skinny on code coverage
I’ve given presentations on code coverage and even written an article on it; however, I must admit that the folks over at Codign Software have done a much more copasetic job of explaining it. Specifically, they’ve succinctly clarified the difference between branch coverage and path coverage in a hip white paper which uses a simple code example and various corresponding test cases. Their write up quickly shows why path coverage is ultimately the better indicator of test coverage.
CoView, Codign’s smokin’ Eclipse plug-in, actually analyzes source code, determines the number of paths through a method (a.k.a Cyclomatic complexity) and creates the appropriate number of JUnit test cases. In CoView version 2.0, existing JUnit tests can be evaluated and correlated back to path coverage, thereby displaying untested paths. This is similar to mutation testing; however, no code is actually changed- only studied.
If you’ve invested into developer testing with JUnit, take a look at CoView- it’ll quickly point out how well those tests actually test. Dig it?
| Related odds and ends | ||
|---|---|---|
Monday 03 Jul 2006 | Code Metrics, Developer Testing
I thought this blog site was supposed to be about disco, so I was going to share my new song with you about the Bee Gees and Maurice Gibb in particular:
When the Bee Gees Were Three
words and music by Dr. BLT (c)2006
http://www.drblt.net/music/beegees.mp3
Oh well, just in case all this techical talk starts to clog up your cognitive functioning, feel free to listen to the song and give me some feedback.
Bruce
aka Dr. BLT
The World’s First Blog ‘n Roll Artist
PS: I’m not only technically challenged, but I realize that I’ve also just given the impression that I can’t spell technical.
[...] Not bad– I’ve got reasonable line coverage here and 100% branch coverage. It turns out the 100% value for branch coverage is a slight defect within Cobertura, but regardless, I’ve got copasetic coverage, don’t I? Check it out, man, the if statement was touched! Because of the short-circuit OR, I triggered a true condition via the 101 value; accordingly, the second clause was short-circuited. The 75% line coverage makes sense too– I failed to execute the else block, hence the other method within the class wasn’t touched and the line coverage value was accordingly deducted. [...]