Code Coverage: How it Works

Bangalore: Code coverage quite simply defines the extent to which the source code of a program has been tested. The target software is usually built with libraries and run under a special environment such that every function executed in the program will be mapped to function points in the source code. This will help developers and Quality Assurance personnel in hunting for parts of a system which are rarely or never accessed under general conditions (error handling and the like). It helps reassure test engineers that the most important test conditions have been checked.

The resulting output is then analyzed to see what areas of code haven’t been executed, and the tests are updated to include these areas. The aim is to develop a manageable yet rigorous set of regression tests.

Test engineers can look at code coverage test results to help them devise configuration sets which can increase code coverage over vital functions. Commonly used methods are statement (or line) coverage and path (or edge) coverage. Line coverage tracks the execution of testing in terms of which lines of code were run to complete the test while edge coverage reports which branches, or code decision points were executed to finish the test. Both report a coverage metric which is expressed in percentage.

Usually code coverage tools and libraries extract a memory or resource cost which is unacceptable to normal operations of the software and so they are used only in labs. As one could expect, there are classes of software that cannot be feasibly subjected to these coverage tests. Such tools could also introduce certain sorts of defects. Specifically some race conditions or real time sensitive operations can be masked when run under code coverage conditions.

Code coverage may be viewed as a more up to date version of debugging. The automated tools which are used to achieve Statement and path coverage are often called “debugging utilities”. These allow the program code under test to be observed on the screen while running. There is an option of defining pinpointed lines of code as ‘breakpoints’, which permits a large portion of the code to be executed, then stops at the point and displays that portion of the code on the screen. Deciding where to put the break points is based on understanding of the program. The data values held in program variables may also be scrutinized and in some cases carefully altered to try out “what if” scenarios. It is useful for a tester to clearly understand the concept of a debugging tool.