Maintaining Your Test Coverage

/via https://www.monkeyuser.com/2017/unit-tests-coverage-degradation/

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

  1. Somebody reports an issue
  2. You poke around in the code, half-remembering how stuff works, and eventually produce a fix
  3. 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
  4. 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…

(•) “Legacy Code — It’s Everywhere

(This article also appears on my blog)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade