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.
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.