Audit Tests

Audit Tests

Audit independent proof: what bug would escape if this test disappeared? The result is a map of contracts to their surviving tests, with evidence for what to keep, repair, combine, or remove. Fewer tests is not the objective; less maintenance for the same or better confidence is.

write-tests owns how to write and falsify a test. This skill owns whether that test adds proof and where that proof belongs. review owns closing out the resulting changes.

Workflow

1. Bound the audit. Read the repository and scoped instructions, then pick a production responsibility. Find its tests, fixtures, shared suites, and CI selection rules. Record the starting revision, local changes, and test results before editing. Distinguish existing failures from checks that could not run. For a focused audit, choose a few substantiated candidates; for a subsystem sweep, use the completeness rules below.
2. Trace the claim. Read each candidate in full, including parameter rows, beside the production entry point and the code it reaches. Inspect callers, sibling implementations, overlapping coverage, and the history explaining why the test exists. Inspect dependency code or types when the claim rests on dependency behavior. Write down what the assertions actually detect, even when the test's name promises something else.
3. Record a disposition before editing. Use the evidence record below. Share findings as they become clear; the workflow must not hold back a material discovery. An audit-only request ends with this evidence and a proposed batch, not with deletions.
4. Choose the surviving owner. Look across the records for whole redundant layers, not just individual weak assertions. Name the suite that will own each contract and every unique case it must absorb. Prefer a real path with controlled external dependencies over replaying internal collaborators. Another layer earns coverage only for a failure the chosen owner cannot expose, such as routing or lifecycle behavior.
5. Change one coherent boundary. When implementation is in scope, carry unique cases into the surviving suite using write-tests before removing their old home. Extend existing cases and fixtures instead of cloning setup. Remove newly unneeded test hooks and support code in the same batch; verify production consumers before deleting an export, wrapper, reset function, global, or injection parameter. Update test discovery and CI registration when moving suites.
6. Prove preservation. Compare the removed assertions with the survivors, looking for lost contracts and assertions that cannot fail for the intended reason. Falsify repaired or transferred regression coverage using write-tests. Isolate temporary production changes, restore the original bytes without disturbing other work, and confirm the targeted proof passes. Report baseline failures separately; investigate any new failures. Run owner and sibling suites, then required repository checks. When replacing static checks, exercise the actual command or dry-run whose contract they claimed. Keep files stable while a runner reads them.
7. Close the batch. Run review, then reconcile the evidence record with what shipped. Report unresolved failures and unrun checks explicitly. A clean smaller suite does not prove removed coverage was redundant; the contract map and preservation evidence do.

Evidence record

For each candidate, record its location and name, actual detectable failure, reason for existing, production consumers of any supporting hook, and decision:

• Keep: identify the independently protected contract. A file move alone does not change this decision.
• Repair: preserve the contract but replace an assertion that is weak, misleading, or attached to the wrong boundary.
• Combine: identify the destination suite and the unique cases it must prove before the original goes away.
• Remove: identify stronger surviving proof, or demonstrate that there is no contract to protect. Suspicion of duplication is insufficient.

Include the supporting source/history evidence, cleanup unlocked, risk, and validation command. Missing evidence stays an open question, not a deletion.

False confidence

Use these as investigation prompts, not automatic removal rules:

• Circular evidence. Expected output comes from the same helper being tested; a fixture copies an inventory from production; a test compares a value with itself. Find an expectation independent of the implementation.
• An exercise without a claim. Executing lines, copying identities, or listing exports may raise coverage without detecting a credible defect. Determine whether execution itself enforces anything meaningful.
• The harness does the job. A mock implements the promised behavior, a fixture supplies the acknowledgement or ordering production must generate, or a persistence assertion reads a store the real path never writes. Using one identical fake for different dependency APIs can hide their differences.
• The wrong cause goes red. A negative case hits a different guard or never reaches the intended branch. Verify the failing condition, not merely that something rejected the input. Check that every parameter row reaches its claim.
• Declarations posing as behavior. Source greps, import lists, capability flags, and internal call shapes can certify the declaration while the user path is broken. Trace the behavior the declaration promises.
• One proof repeated. Private helper tests, per-provider replays of shared logic, and multiple layers exercising the same regression can all protect one contract. Keep distinct transport and lifecycle risks, not copies of the same scenario under different filenames.
• Tests keeping code alive. A helper or production escape hatch exists only because tests call it. Move proof to the real entry point and remove the abandoned mechanism; do not replace it with another test-only abstraction.