Test Coverage

You might say

Do not only report “90% coverage”; also show whether the high-risk path combining payment failure and a coupon was actually tested.

Test coverage measures how much of requirements, code structure, or risk paths have been reached by tests.Branch coverage can show whether the coupon-plus-payment-failure combination was reached; a requirements matrix can show a missing payment case. Coverage finds untouched paths. It does not mean no defect or meaningful assertions, even at 100%.

Know first

Unit Test

Test CoverageCode CoverageCoverage

How a payment map shows tested and untested risky branches

Checkout decision pathsGreen = exercised by a test

Submit order

Payment succeedsConfirmation

Payment failsRestore cart

Coverage is useful when it reveals unexercised risky paths, not when it is only a percentage.

What to inspect beyond the coverage number

Coverage shows reach, not reliable outcome: A code line or branch executed only means a test passed through it. Without checking the right result or modeling a real risk, a high number cannot prove payment behavior is right.

Fill untested high-risk paths first: Inspect real risks such as coupon combinations, payment failure, and insufficient permission rather than pursuing one global percentage. A map of tested and untested requirements guides action better than a number alone.

Quick checkChoose the best answer

A report says 100% code coverage, but the page still says “order succeeded” when payment fails. What is the best conclusion?

Coverage does not prove assertions or user results are correct; add an observable payment-failure case100% coverage proves there are no defectsIgnore this occasional symptom because the number is high

You can say this to an AI Agent

Report payment-flow coverage, not only a percentage: list whether success, payment failure, coupon combination, and insufficient permission are tested. Prioritize untested high-risk branches and verify each user-visible result.

Learn next

1Regression Test→2Test Case→