At Centrum we are often brought in by organisations that want to improve the quality of their software deliverables and remove some of the unwanted “excitement” from the delivery process. We love engagements like this because it means that the client understands that there is a cost to neglecting to focus on quality and that they are open to changing processes and tools to move forward and start paying off that technical debt.
Unit test coverage – the easy bit…
How a drive for change often starts is that a new “green fields” project is chosen and high unit test coverage is encouraged (or enforced) perhaps along side practices such as TDD. The benefits can be seen by the team involved in the project and this message is taken on board by management. Unit Testing has been deemed to be “a good thing”.
So now for the legacy code…right?
So now the organisation or team has bought into the benefits of having a good level of unit test coverage and want to roll it out to all their projects. However, the problem seems insurmountable. The code analysis shows that your current coverage is at < 2%. How do you get up to your target? Often the response is to only enforce coverage on the new projects that were built from day 1 enforcing high coverage. This can mean that you are actually enforcing standards on a tiny proportion of your organisations code. Another option is of course to invest in writing the test cases for legacy code. However, this investment is rarely made made nor is it necessarily recommended. Test cases are most valuable when written before 0r at the time that the code is written.
The third way. Ratcheting up coverage
What we often recommend when we hit the situation outlined above is to take a continual improvement approach. Find ways to gradually improve the quality of your code and build momentum. Find some metrics that can show a positive view of the improvements been made, don’t simply compare your legacy projects 2% coverage with your green fields project at 80%. The 80% is an impossible short-term target and actually acts as a disincentive to improvement.
Sonars now reports coverage of recent changes
Sonar has just introduced functionality to show the coverage on recent changes. This allow you to enforce coverage on every line of code added or changed during a project and over time your overall coverage will get there. It also has the effect of introducing tests for those parts of your code base that change more frequently and therefore get the most value out of them.
What is also pretty neat is the ability to show the source code marked up with only the code that is untested, but only for the period that you are interested in. This gives developers the feedback they need to write tests that cover changed code.
Footnote: Sonar for the uninitiated
Sonar is an open source quality platform. It collates and mines data from a variety of code analysis tools as well as it’s own in built ones to give you a holistic view of the quality of your software. The “7 axis of code quality” as described by Sonar are: ArchitectureDesign, Duplications, Unit Test, Complexity, Potential Bugs, RulesFormatting & Comments (Documentation).