Code Coverage

Code coverage measures which parts of production code are exercised when tests run, but it does not directly measure whether those tests are correct or effective. Common forms include line, branch, and method coverage.

Code coverage is a test metric that records which executable parts of an application are reached during a test run. A coverage report can show, for example, that tests executed a particular method or line of Java code.

Line coverage asks whether executable lines ran at least once. Branch coverage goes further by checking whether alternative outcomes of control flow, such as both sides of an `if`, were exercised. Method coverage records whether methods were invoked.

High coverage does not guarantee high-quality tests. A test can execute many lines while making weak assertions, missing important edge cases, or failing to detect an incorrect implementation. Coverage is therefore evidence about test execution, not proof of correctness.

In Java projects, coverage is commonly collected by build and test tooling and then inspected as a report. A useful engineering practice is to examine uncovered code and decide whether missing tests represent meaningful behavior rather than treating a percentage as the sole testing objective.

Key points

• Line coverage measures executed lines.
• Branch coverage checks different control-flow outcomes.
• Coverage shows what tests execute, not whether assertions are meaningful.
• High coverage does not imply high test quality.
• Use coverage to identify testing gaps, not as the only measure of test effectiveness.

Interview questions

What is code coverage, and why is it useful?

Code coverage measures which parts of the application are executed while tests run. It can reveal code that existing tests never exercise. For example, a coverage report may show that an error-handling branch has never been reached by a test. It is useful for finding potential testing gaps, but it does not prove that the tests are correct or comprehensive.

What is the difference between line coverage and branch coverage?

Line coverage asks whether executable lines were executed during tests. Branch coverage examines alternative outcomes in control flow, such as the true and false paths of an `if` statement. A test can execute a line containing an `if` while covering only one of its possible outcomes. Branch coverage therefore provides additional information about conditional behavior.

Does 100% code coverage mean the code is well tested?

No. It means the measured code elements were exercised according to the coverage metric being used. Tests could execute every line while making weak assertions or omitting important input combinations and failure cases. For example, a test might call a method and never verify its result. Coverage should therefore be combined with meaningful assertions and behavior-focused test cases.

How would you use code coverage when reviewing a Java service?

I would first look for important production paths that tests never exercise, especially error handling and boundary conditions. Then I would inspect whether the existing tests make meaningful assertions rather than simply executing methods. I would pay attention to branch coverage for logic with multiple outcomes. I would use the report as a diagnostic tool rather than trying to maximize the percentage indiscriminately.

What is a sensible way to interpret a coverage threshold in CI?

A threshold can provide a guardrail against large regressions in test coverage, but it should not be treated as a proxy for test quality. Teams should choose thresholds that fit their codebase and examine important uncovered behavior separately. It is also useful to distinguish new or changed code from long-standing legacy code when designing enforcement. The goal is to prevent meaningful deterioration while keeping engineering attention focused on behavior and risk.