having 100% code coverage doesn’t solve all your problems, having less solves even less.

I recently came across a post about achieving 100% code coverage and how reassuring it is. But is it? 

What does 100% code coverage mean? Ignoring the different definition it basically says that all your code was executed ( covered ) during the tests. (the definition of “all your code” is a bit flexible here) But does that say anything about your code quality or about the quality of your tests? 

The answer is no. And it’s a big NO because having a full coverage doesn’t mean your code does what it should. Remove all the assertions from your tests and you still have 100% coverage, but with no quality assurance whatsoever. The only real advantage of 100% coverage is that you know there is no unexpected exception thrown (unless you did something real nasty like @expected(exception) in your tests, but then you had it coming). At least not when executed the way you did.  (yes 100% coverage doesn’t mean you covered all possible cases, just all code). 

On the other hand, having less than 100% means you missed some code and therefore definitly don’t know how it behaves in production. 

Long story short: 100% code coverage is a good thing to have, but it’s like being able to type fast: good to have but when it comes to quality coding you need much more than that.