THE GITHTML FIELD GUIDE
Review test coverage by reading assertions, not percentages
A useful test review asks what behavior each assertion protects and which failure it would detect. Inspect setup, assertions, and important boundaries rather than relying on test names or coverage percentages. Distinguish an existing test from one that actually ran successfully, and record the risks that remain outside the review.
Choose a risk and follow its evidence
An illustrative risk is duplicate submission creating duplicate records. Start with that behavior, then locate tests that claim to address it. The Practical Test Pyramid offers context for selecting different test levels, but no fixed shape proves that a particular risk is covered. Read the setup to see whether it represents the relevant conditions. A test named prevents duplicates may only verify that a button becomes disabled, leaving the persistence behavior unexamined. The review should describe this gap without dismissing the useful interface check.
Inspect the assertion and its failure mode
Ask what change would make the test fail. If the assertion checks only that a function returns something, it may not protect the invariant named in the test. Review boundary values, error paths, and isolation from unrelated state. Distinguish a realistic integration dependency from a mock that guarantees the result under discussion. An illustrative checklist for the duplicate case includes repeated requests, concurrent attempts when relevant, and a failed first attempt followed by retry. These are review prompts, not a universal requirement for every feature.
- Risk: name the user-visible failure the test is meant to detect.
- Assertion: identify the exact property checked and its meaningful failure condition.
- Boundary: record important cases that are covered, missing, or outside scope.
Keep review findings reproducible
Link to test and implementation at the reviewed revision. If you run tests in an authorized local environment, record the command and result; if you only read them, say so. Avoid equating a source review with a passing test suite. Prioritize missing protection by consequence and propose the smallest useful follow-up. For a phone-friendly HTML summary, show the risk, evidence, and gap in short sections, with long output in a separate appendix. gitHtml reads that report but does not execute tests or calculate coverage.
Sources and further reading
AI-assisted writing with source-linked guidance and illustrative examples. Read our editorial approach or report a correction.