Test adequacy review

Test Adequacy Review

A passing test suite is only as trustworthy as what its assertions actually prove. Never equate test file count or line coverage with correctness; inspect what the tests actually execute and assert.

Workflow

1. Verify that tests exercise the real modified code path:
   • Check whether the test calls the actual production function, endpoint, or component, or whether over-mocking replaces the very logic that was changed (testing the mock instead of the code).
   • Ask the mutation question: "If I reverted the core logic line in the production diff or flipped an if condition, would at least one test in this PR fail?"
2. Audit assertion quality and specificity:
   • Flag weak or tautological assertions (expect(res).toBeDefined(), expect(fn).not.toThrow(), or only checking HTTP 200 without verifying the returned payload or persisted database state).
   • Verify that tests assert both positive outcomes (the right record changed to the right value) and negative invariants (other tenants' records, unauthorized fields, or rejected states remained untouched).
3. Check coverage of failure, boundary, and regression cases:
   • Confirm that the test suite covers:
     • Each explicit acceptance criterion from the specification.
     • Key rejection paths (invalid input, unauthorized actor, conflicting version/state).
     • For bug fixes: a deterministic regression test that reproduces the exact failure mode before the fix and passes after.
4. Distinguish missing tests from proven product bugs:
   • A missing or weak test is a verification gap, not automatically proof that the production code is broken. Report missing test coverage clearly as a test-adequacy finding and specify the exact scenario that needs a test.