Statement coverage

Statement coverage is a white box test coverage measure: the share of a program's executable statements that the test suite runs at least once. It is calculated as executed statements divided by total statements and is the weakest of the structural measures, because running a statement says nothing about whether every outcome of a decision was tried.

The longer version

A coverage tool instruments the code, runs the tests and reports which statements were reached. If a function has ten statements and the tests execute eight, statement coverage is 80 per cent, and the two unreached statements are listed. That list is the useful output: it points straight at code that no test has ever run, which is where an untested behaviour is most likely to be waiting.

A short example shows how little a full score proves. In a function that contains a single `if` with no `else`, one test where the condition is true runs every statement and scores 100 per cent, yet the false path was never exercised. Branch coverage closes that gap by requiring each decision to be taken both ways, and condition and path coverage go further.

Line coverage is the figure most tools actually print, and it is close but not identical, since one line can hold several statements and one statement can span several lines. A high number, whichever form, shows that code was executed, not that anything was asserted about the result: a test that calls a function and checks nothing raises the percentage and proves nothing.

As a floor, the measure is helpful. A low figure reliably means large untested areas, and a coverage gate in the pipeline can stop a change that adds code with no tests. As a target, it invites tests written to push the number up. Statement coverage finds what has not been tested, and says very little about how well the rest was.

Common questions

What is statement coverage?

The proportion of executable statements in a program that the tests run at least once, expressed as a percentage. A tool records which statements execute during the test run and compares that count with the total, so the result shows how much of the code has been exercised at all.

How is statement coverage calculated?

Divide the number of statements executed by the total number of executable statements and multiply by 100. If tests run 45 of 50 statements, coverage is 90 per cent. Comments, blank lines and declarations that produce no executable code are normally left out of the total.

Does full statement coverage mean the code is fully tested?

Full statement coverage only shows that every statement ran. A decision whose false branch has no statement of its own can go untested, and a test that executes code without asserting anything still counts. Stronger measures such as branch coverage and good assertions are needed for real confidence.

What is the difference between statement coverage and branch coverage?

Statement coverage counts statements run. Branch coverage counts decision outcomes taken, so each `if` must be exercised both true and false. Branch coverage is the stricter measure: reaching it also reaches full statement coverage, but a suite with full statement coverage can fall short of it.

What is a good statement coverage target?

Teams set their own thresholds, and no single figure is correct for every codebase. A threshold works best as a minimum that blocks new untested code, not as a goal to maximise, because pushing the percentage up with weak tests makes the number look better without the product being safer.

Bug reports that arrive ready to triage.

Collect replay, console, network and browser context with the Free plan.

<script src="…/widget.js" data-key="pb_pub_…">