Code Coverage And How To Effectively Utilize It

In recent times, there have been discussions in the social media and blogs about the utility of code coverage metric. For a Software Tester who is analyzing code as part of their white-box testing strategy, code coverage could be useful. In this blog, let us look at how to effectively utilize the code coverage mechanism to analyze the quality of code.

First of all, anything that bundles a heap as a number is ineffective. It does not really mean anything when someone says 80% of their code is covered. It does indicate that that much percentage of their code has been visited by the test runs, but does that tell you which portions of the code were visited? The key is in identifying portions of code that were not visited.

Unvisited code can mean many things, the following are a few, but this list is in no way comprehensive. There could be other factors too.

• Test scenarios are not available to execute that portion of code
• The unvisited code portion is not reachable / useless and can be removed
• The unvisited code portion is not testable

The key is to focus on the unvisited portions of code and see why they are unvisited. Unvisited portions of code are dangerous and can lead to conditions in production that were not conceived during internal tests. When multiple systems are integrated as a solution, or when the software runs for a prolonged period of time, there are chances that the unvisited code could get executed leading to system outages or crashes due to unforeseen defects.

Focus on unvisited portions on code, and relentlessly include appropriate tests, refactor and remove code portions that will never be executed, and make unvisited and non-testable portions of code testable. This is presuming that your covered code has valid tests that test against the system’s requirements.

On white-box testing and code coverage strategies, feel free to contact me.