It’s unarguable that Continuous Delivery has gone from being just a CTO friendly buzzword to a central requirement for a high performance delivery team. It’s no longer cutting edge to merely check in your code to source control and have Jenkins or other continuous integration box run the unit tests. You have to be able to get that code out into a live environment as fast as possible and that means Continuous Delivery. The ability to deliver code into production at will has a direct effect on your bottom line but to do this effectively you need two things, 1) understand the important areas of functionality that the customers really use and 2) be able to test these areas as quickly and easily as possible. The first is a business issue but the second boils down to automating your testing.
The trouble is that most of the industry holds on to a quality assurance process that is directly at odds with this. The reasons are mostly historical but companies have had varying levels of success in the drive to automate QA. The level varies on how highly the company values this ability. So what levels of QA do we commonly see?
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.