6.3 Coverage, Oracles, And Test Quality
Coverage is a useful signal, but it is not quality itself. Coverage says "this code executed." It does not prove the test checked the right behavior, and it does not prove the important risks were covered.
One test can execute 100 lines with no meaningful assertion. Another can execute 10 lines and catch the most dangerous business boundary.
What Coverage Can Tell You
Coverage helps teams find obvious gaps:
- Branches that never execute.
- Error paths with no tests.
- New code that the suite does not touch.
- Risk introduced by deleting tests.
But coverage cannot tell you:
- Whether assertions are correct.
- Whether scenarios represent real risk.
- Whether test data includes boundaries.
- Whether tests would catch a wrong implementation.
Coverage belongs on the checklist, not on the throne.
Oracles Decide Whether Tests Catch Wrong Behavior
A test oracle is the rule that decides whether the result is correct. "Returns 200" is not a complete oracle. For a payment API, you may also need to check amount, order state, idempotency, audit log, and error code.
High-quality tests usually check:
- Explicit output.
- State changes.
- Side effects that must not happen.
- Exceptions and failure paths.
- Business invariants.
Improve Tests By Following Risk
When improving test quality, do not chase the number blindly. Ask sharper questions:
- Which high-risk areas only have happy-path tests?
- Which tests have no assertions?
- Which production incidents left no regression test?
- Which complex branches have no boundary cases?
- Which tests fail often but nobody trusts?
If a team already has high coverage but defects still escape, the next step is not simply adding more tests. Audit whether the tests are checking important behavior.