There is a common misunderstanding regarding code coverage of unit tests. To make it short: Code coverage doesn’t tell you anything about whether your unit tests work. The only thing they tell you is which code lines are covered with the unit tests in place.
A lot of times it is very, very easy to achieve 100 percent code coverage with a few simple unit tests. If the unit you’re testing doesn’t have any conditions you might get away with one test which will execute every code line and get a perfect code coverage score.
Well, duh. That doesn’t mean your code is thoroughly unit tested.
However, there are good reasons why you should look out for code coverage and reach for the best coverage you can get. I usually only check my code coverage at the end of a unit test writing session. If I thought of everything I should get a 100 percent coverage. If the code coverage is less than expected it’s a good chance I missed something.
In other words, just because your code coverage for a tested unit is great doesn’t mean that you’ve tested everything. It also doesn’t tell you whether your tests are actually correct. The brainwork is still up to you and any code coverage analysis can’t help you there. However it’s a nice way to make sure that you didn’t forget something obvious, like forgotten to test the other condition.
I regularly run PartCover to check code coverage of implemented features and I regularly find untested code lines. Most of the times these are due to small changes or bug fixes, when we just forgot to add a test for that simple change we made.
So, while code coverage tells you nothing about the quality of your unit tests, it is a great way to find any open gaps – however small or big – in your existing tests.