Maintaining Your Test Coverage

“Code is either growing or staling”
— Me
When we think of Legacy Code, we usually think of it as a pejorative. If we’re a bit more enlightened, we might think of it as “all the code you’ve written, all the frameworks from the past, all the processes that exist to deal with edge cases, and all the skills that you no longer use” (•)
Which is all well and good, except that one of the most important components of legacy code is all the tests embedded in it.
Think about it this way — it’s really pretty hard to maintain test coverage on your existing code, right? Now imagine doing this for one of the legacy systems. The sequence probably goes like this
- Somebody reports an issue
- You poke around in the code, half-remembering how stuff works, and eventually produce a fix
- OH NOES, some of the tests staled out due to the fix, others ‘cos data has changed, and that’s before you even get around to not adding tests for the stuff you changed
- Seriously, you probably don’t really add all the tests you should because, well, you barely remember how the stuff works in this system
And so it goes. The inevitable degradation in test coverage. And remember this is for pretty much any system that you aren’t actively maintaining. Which, as time progresses, refers to an increasing percentage of your code-base!
You’re doomed, doomed I tell you…
