Cobertura is a great free code coverage tool. I've used it a little in th past, but I'm rusty. It has a maven plugin too.
...
Aw. For cry'n out load. That was too easy! The maven integration really shined this time. All I had to do was go the the cobertura maven plugin page, grab some xml for my pom, then run
mvn cobertura:cobertura and, ta-da, there's my coverage reports!If you've never done code coverage before, you should. Especially when it's this easy!
But wait, I wasn't able to use it on my last project because it wasn't that easy. So what's the difference? Well, obviously, my little wickety app is dead simple. The other project had all sorts of things going on like JSPs, applets, web-services, JMS, legacy home grown persistence management, blah, blah. blah. Parts of it were designed to be tested with JUnit. Parts used home grown test classes. Most relied on human testing. Of the JUnit and test-class tests, most were stale and broken. Bottom line: TDD (and coverage etc.) was not part of the project culture and so it was like forcing a square peg in a round hole.
I'm starting on a new project next week. It is still in its early stages and looking very waterfall-ish. My intention is to bring TDD and automation in immediately so it has a chance to take root. One issue to be addressed is whether we will use wicket or JSF. Seen from a TDD perspective, I think it boils down to this: TDD can be done with either but will be more effective when there are less impediments. Supposedly JSF can be tested automatically, but only in a container so far. The TDD I did yesterday didn't need a container and, so, was very straight forward and clean. TDD has been part of the wicket culture since the beginning (as far as I know) and it shows.
So. Back to my little wickety app.
Code coverage is great. But so far I still need to run it manually. Not good. ... Time for continuous integration! (to come)
No comments:
Post a Comment