I Used to Think 100% Code Coverage Was Silly

When learning about testing years ago, I was supporting an embedded C++ project. I actually had to build a coverage tool because the one provided by our toolchain didn't work properly. Any way, we were all in agreement- the hoops you have to jump through to get to 100% coverage were kind of silly- not a lot of value add for the hours spent. I carried this attitude with me.

The last year I have gotten to work on a couple Greenfied open source projects (check out my gitlab). I was doing mostly TDD so had a good amount of happy path coverage. One day though, I decided to look at the spots I was missing.

Turns out basically every spot that wasn't covered was some sort of error handling code. As a challenge, I decided to fill it out. What did I discover? Basically none of it worked the way I hoped. Getting to 100% made sure all those edge cases worked properly...and even let me remove some error handling that was impossible to hit.

So as of now, I believe in 100% code coverage. Obviously on an existing project with little to no testing there are bigger fish to fry, but if it's doable, you should do it...even if it just means not adding all that reflexive defensive code that may or may not actually help.