I wrote a simple post a few years ago on unit testing your logging. Checking my logs I’ve seen that it’s always been a popular post as it appears to be something that lots of people want to do.
My previous version was based on log4j and since many people have moved on to logback I thought I would update it. So here it is 🙂
And that’s it.
It’s not exactly rocket science or exactly a new idea but how many of us treat our test code like our application? I got to thinking about this when Stuart extended our checkstyle checks to include our unit and integration test code. That simple analysis threw up over 300 violations. The vast majority were ones that we ended up suppressing like magic number and visibility modifiers but there were plenty of minor annoyances like various import violations and whitespace violations. Checkstyle is a great starting point but ideally we would want to have our test code undergo the same sorts of static code analysis as our normal code: cyclometric complexity, LCOM4, duplication, package tangle index and whatever else other than code coverage your tool of choice provides.
Apart from being one of the ‘ooh shiny!’ aspects of Agile (and we all know that Agile is the one true way) what it does it ensure the code quality of your test code is the same as the rest of your code. This enforces good code practices and minimises the amount of kruft that can get in your test code and when it comes to refactoring you’ll have a much easier task.
Personally I’m a huge fan of Sonar even if you have to perform little bit of sleight of hand if you have cobertura installed in your maven pom file so that it breaks the build at the test phrase (fast feedback please!) but it really does do everything you need. Once you get your test code hooked up too, you’ll get the same benefits that your application code gets and you’ll thank yourself in the long run.