Fixing Unit Test Coverage through Attrition

I received an email from a colleague who recently changed jobs, and I wanted to share select parts of it for today’s blog.

“… One of the projects I am assigned to is a project with close to 100k lines of code that has been written and maintained over 10 years.  The code coverage for this project is in the low 20% range.  When I asked why the coverage was so low, I was told that the client (who owns the code) does not want to spend the time and money to write unit tests for code that has already been deployed...”

This is not an uncommon story.  Many of us have found ourselves in a position like this, especially if we are developing software as part of a consulting position.  Trying to explain to a client that they should spend money to write tests is fraught with challenges.  From trying to explain why the tests weren’t part of the code to begin with, to trying to justify the ROI of writing tests when it is impossible to measure the value of catching bugs early, you will very rarely get a client to bite off.  Besides, going back and writing unit tests for code that was written by other engineers several years ago is a daunting task anyway.  Sometimes when there are no unit tests and the documentation is lacking, the expected functionality of the units and what you perceive as the expected functionality may differ, leading to even more confusion when you add (incorrect) tests to the mix.

However, all is not lost.  Just because you are working in a project that has low code coverage does not mean that you need to abandon good development practices.  Stick to using Test Driven Development.  Every time you need to make an update to that application, you will be writing unit tests (First rule of TDD - never write any code unless you have a failing test).  Slowly but surely you will begin to see the code coverage increasing… I call it Fixing Unit Tests Through Attrition.  And I know from experience that it works!