Everything you need to know about code coverage

What is Code Coverage?

In software quality development, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs.It helps to identify which lines of your code have been tested and which haven’t, down to the method level.Code coverage is a measurement of how many lines/blocks/arcs of your code are executed while the automated tests are running.They are collected by using a specialized tool.As per Wiki’s definition,“Code coverage is a measure used to describe the degree to which the source code of a program is tested by a particular test suite”,.

To calculate the code coverage percentage, simply use the following formula:

Code Coverage % = (Number of lines of code executed by a testing algorithm/Total number of lines of code in a system component) * 100.

For Example: If the software you are testing contains a total of 100 lines of code and the number of lines of code that is actually validated in the same software is 50, then the code coverage percentage of this software will be 50 percent.

Why Measure Code Coverage?

It is well understood that unit testing improves the quality and predictability of your software releases.

In summary, we measure code coverage for the following reasons:

  • To know how well our tests actually test our code
  • To know whether we have enough testing in place
  • To maintain the test quality over the lifecycle of a project

Suppose a small piece of code for example,

int val(int num){

if(num == 0)

{ //if block

return 100;

}

else

{ //else block

return 1;

}

}

Till now,you tested the code only using val(100) or any other value other than 0.n that case, the “if block” was never executed and hence never tested.Using such a test suite  would give you a code coverage of 50%.Thus Code coverage provides you with the measure that how much of your code was executed by the Test suite. The higher you code coverage the lesser are chances of finding bugs later after deployment. In addition, code coverage is also used for judging the effectiveness of automated Test Suite generation softwares. Code that never runs during your testing is suspect at best. It is best practice to force this code to run, perhaps by adding debugging code to make it run, and see that it does what it is expected to do.Less than 100% code coverage is having code that is running blind. It is unknown if it will perform as expected when it needs to.

How Code Coverage Works?

Broadly there are three approaches, which may be used in combination

  1. Source code instrumentation
    This approach adds instrumentation statements to the source code and compiles the code with the normal compile tool chain to produce an instrumented assembly.
  2. Intermediate code instrumentation Here the compiled class files are instrumented by adding new byte codes, and a new instrumented class is generated.
  3. Run time information collection This approach collects information from the run-time environment as the code executes to determine coverage information.

Types of Coverage measured

  1. Statement
    Statement coverage measures whether each statement is executed.
  2. Branch Branch coverage (sometimes called Decision Coverage) measures which possible branches in flow control structures are followed. Clover does this by recording if the Boolean expression in the control structure evaluated to both true and false during execution.
  3. Method Method coverage measures if a method was entered at all during execution.
  4. Path  The flows containing a sequence of controls and conditions that have worked well at least once.
  5. Function Coverage The functions in the source code that are called and executed at least once

Code coverage of 70-80% is a reasonable goal for system test of most projects with most coverage metrics.Minimum code coverage for unit testing can be 10-20% higher than for system testing.So then, what’s an ideal coverage percent you ask? Well, the only focus and goal of developers and testers should be to write test scripts that aren’t vague. Don’t focus to achieve 100 percent coverage. The analysis should be clubbed with scalable, robust test scripts, covering every functional and non-functional area of the source code.Summing up,developers and testers have to intensify the rapidity of their software development life-cycles. And to handle tight deadlines.Hence, good code quality is what every developer or tester is aiming for. With a code coverage analysis report, they can track the proportion of code that worked well under test scenarios.

However, depending on coverage metrics solely for assessing code health isn’t a good option.