Code Coverage and nothing is too simple to test

So time to look back again and update some old opinions from June 2008. And while there are some other useful stuff in there I'll focus on code coverage and testing simple things. Because I feel the urge to explain myself...

First of all this long piece on code coverage and how I think you should have certain targets. What was I thinking? Somebody should have called me out on that post a long time ago since it sounds like I'm suggesting code coverage as a good metric. I do call out it does not measure quality but high coverage actually doesn't tell you anything other than that you have high coverage. Small numbers as a result of running tests are way more valuable as it indicates that tests are missing. Never forget that; high coverage = who cares, low coverage = warning signal. So yes it is valuable to measure code coverage as a result of running tests but aiming for certain (high) numbers is useless...

Then there is a follow up on things that are too simple to test. Well this one is interesting as I still think the statement that if something is really simple then the test for it is also really simple so you should write it. That does not mean I write tests for every auto-property I create. Because typically those are, for code coverage purposes, covered by some other test actually using those properties.

A more important change of mind I've had in the last 8 years is that I'm no longer a code coverage addict who uses 100% coverage to show others what a strict BDD/TDD practitioner I am. Mainly because I've come to believe that the most valuable unit tests are the ones that test complicated or important things - not ArgumentNullExceptions. And since all C# projects that I've been working on (ever) have used FxCop there is a better tool that writing unit tests to make sure I validate my arguments for null before I use them.

That is, we should always use the best tool for the job we want done; FxCop is great for making sure you validate before referencing something that could be null so it is more about using the right tool rather than writing tests just for the hell of it. But the original statement still holds; if you have a simple thing, not checked by some other tool then I still believe your should write that unit tests to document your intention for future developers; because if the simple thing is hard to test then it is not a simple thing...