1. Home
  2. Smartpedia
  3. Code Coverage

Code Coverage

Knowledge at a glance: Code coverage expresses what proportion of the source code – statements, branches, paths, and conditions – is executed by test cases.

Code coverage – evaluating the quality of test cases

“How much do we have to test?” – Every development department has to answer such a question. One answer to this question is the so-called code coverage. It expresses what proportion of the source code – statements, branches, paths, and conditions – is executed by test cases.

Code coverage – sometimes called code overlap – is expressed as a percentage. Without test cases, the code coverage is 0 percent. A high code coverage ideally reduces the development risk, but in the narrower sense says little about the quality of the tested source code, because a high coverage can also simply be a sign for many test cases.

Metrics to determine code coverage

There are several metrics for determining code coverage:

  • Tested statements / statements. This metric is called statement coverage or C0-Coverage.
  • Tested Branches / Branches. This metric is called Branch Coverage or C1-Coverage and refers to program loops.
  • Tested paths / paths. This metric is called Path Coverage or C∞ Coverage and refers to program paths. Due to the combination of all loops and paths, which in many cases can be traversed multiple times, the number of paths is potentially infinite and a complete path coverage is therefore not realistic.
  • Tested conditions/conditions. This metric is called predicate coverage of conditions, condition coverage or C1p coverage and addresses all predicates (i.e. all terms and partial terms).

In addition, various publications also mention decision coverage as an extended view of branch coverage and multicondition coverage as coverage of all condition combinations.

The metrics essentially determine the relationship of the test cases to the code or to individual code components and are regarded as a quality indicator for the test cases. Complicated code is difficult to test, a high code coverage is therefore a sign of good test cases. One criticism of the concept of code coverage is the neglect of actual test results. Whether a test was successful, whether and how many errors were found is not the focus of the code coverage.

In software development, it makes sense to define test cases on the basis of requirements. However, this does not ensure that all corresponding code parts are covered. Requirements can be implemented in different ways, so that there are correspondingly different reference points for tests. The requirement coverage is therefore not identical to the code coverage.

The principle of coverage can be applied to numerous artefacts. So it can give for example a draft, a module, an architecture, a data or a function coverage. They can be determined exactly like the code coverage with a simple relationship: Coverage = tested elements / specified elements. 

What does t2informatik do?

Was does t2informatik do? One click and you'll know it.


Code coverage analysis is also recommended as a practice for implementing clean code.

Here you will find additional information from our Smartpedia section:

t2informatik Blog: The implementation of Clean Code

The implementation of Clean Code

t2informatik Blog: Sense and Nonsense of Unit Test Coverage

Sense and Nonsense of Unit Test Coverage