Test coverage metrics considered actively harmful

This is a fantastic blog post from James Shore on making sure you have the right tests, tests that will save you from stuff instead of simply trying to push up an abstract number. It’s a great read and thought provoking. For example:

If you’re using test-driven development, don’t measure unit test code coverage. It’s worse than a useless statistic; it will actively lead you astray.

To build up tests in legacy code, don’t worry about overall progress. The issue with legacy code is that, without tests, it’s hard to change safely. The overall coverage isn’t what matters; what matters is whether you’re safe to change the code you’re working on now.

Of course, no advice is the right advice in 100% of situations and he points out some useful counter-examples too. But I loved this pragmatic approach to testing.

So instead, nurture a habit of adding tests as part of working on any code. Whenever a bug is fixed, add a test first. Whenever a class is updated, retrofit tests to it first. Very quickly, the 20% of the code your team works on most often will have tests. The other 80% can wait.