100% code coverage to the rescue | Patrick Smacchia
Every single programming day, abiding by the simple idea… if a class is covered by tests, cover it 100%… sheds light early on many potential bugs and problems, before they end up screwing at production time.
For example, today I worked with a XML parser class that was 100% covered. After a refactoring session, it was not 100% covered anymore. But still all tests were green! The uncovered sequence points are shown in red:
Something was wrong since all these seven return false; sequence points used to be covered before the refactoring occurred! After investigating, it appeared that the line TryGetIntegerFromNexTAttribute(TAG_FIRST_STATEMENT_LINE… was added during the refactoring session. However unit-tests were not modified to take account of this new behavior. The 7 unit-tests concerning the 7 return false; sequence points, were all green, but it was because they were missing the TAG_FIRST_STATEMENT_LINE xml attribute.
These 7 unit-tests were out-of-sync with the code and if the 100% coverage ratio was not checked, we had no way to figured out this issue. Having green unit-tests out-of-sync is a bug in the unit-tests set, not in the code base itself. But this situation can certainly lead to more serious problems in the future.
Hence having green unit-tests is not enough. Classes covered must be – and must remain – 100% covered.
Btw, to check continuously that a class is 100% covered, we tag 100% covered classes with a FullCovered attribute…
…and we have a corresponding CQL rule : Types tagged with FullCovered attribute should be 100% covered by tests. An extra benefit is that, thanks to the FullCovered attribute, a developer working with a 100% covered class is aware that a complete test suite exists for this class.