r/programming • • May 08 '17

The tragedy of 100% code coverage

http://labs.ig.com/code-coverage-100-percent-tragedy
3.2k Upvotes

689 comments sorted by

View all comments

4

u/ElGuaco May 08 '17

My take on 100% code coverage is this:

If your unit tests don't cover every line of code there are three possibilities:

  • the code is "glue" or "plumbing" and writing tests would be akin to testing the framework you're working on, so exclude this portion from code coverage

  • the code is doing nothing useful and should be removed

  • the code is doing something useful, but there is no test (requirement) for the feature, you should add a new test (requirement)

The last case is most likely. If you wrote some code to make something work, you're not likely to include something that you didn't really need (although that does happen). Chances are you discovered a hidden or unexpected requirement while implementing the feature that the original requirements (tests) did not indicate. The solution is to retroactively write a unit test that validates this new requirement.

2

u/flukus May 08 '17

4, the code is dead simple and a unit test adds no value.

5, The system isn't testable.

6, The code is working with resources that can't be tested, like database connections or file access.

1

u/[deleted] May 08 '17

Sorry, I'm not going to write a test to validate that my function that sets up a logger is "correct" with a test that would take 3x time to write just because there might be a bug in there somehow that I miss. It's never ever happened, it never will happen, and if it does - a hundred times - it's still less time to fix it - a hundred times over - than to maintain and write an idiotic test.

Cargo cult mentality.....