Test Quality Audit

A test is worth keeping when it fails on a realistic regression of a contract, meaning behavior that users or callers rely on. Judge every test by that standard. Coverage, test count, and whether the test was written first do not count. A small suite whose failures point at real defects is better than a large one, so do not ask for more tests by default.

Call a test weak only when the evidence shows it protects no contract or costs more to maintain than it protects. If missing context prevents that judgment, say so instead of assuming the test has little value.

What to read

Start with the tests under review, then read only what you need to judge them:

• the implementation under test and its public or user-visible behavior
• important branches and failure paths
• fixtures, mocks, factories, snapshots, and helpers
• existing tests for the same behavior
• the PR intent, bug report, or known regression when available
• the commands, selection rules, and prerequisites that decide whether the tests run
• external boundaries: database, API, auth, queue, filesystem, time, randomness, network

Keep reading only while a test's claimed behavior, a real dependency, a risky branch, or nearby stronger coverage is unclear.