svk1998/test-audit

Test Audit

This skill has two modes:

• Authoring. The authoring gate below applies to every test you add or change.
• Auditing. Remove low-value proof in coherent batches grouped by production owner. Never chase deletion counts; the goal is a suite where each contract has one strong owner, not a smaller number.

For a campaign that prunes a whole subsystem's test surface at once, read CAMPAIGN.md first.

Authoring gate

Before adding a test, answer these four questions:

1. What observable behavior, invariant, or independent contract does it protect?
2. What credible regression would make it fail?
3. Why does the existing proof miss it? Each contract should have one primary owner at the strongest boundary. A test at another layer needs a distinct transport or lifecycle risk to justify it. Extend existing tables and shared fixtures rather than adding near-copies, and consolidate repeated setup.
4. Does it need an export, flag, wrapper, or injection hook that has no production caller? If so, move the proof to the real boundary instead.

Supporting rules:

• Use the boundary and cost guide to choose where the test lives and what it may cost.
• A regression test must fail before the fix for the intended reason and pass after the repair. If you cannot show the pre-fix failure, say so in your report.
• One regression at the owning boundary covers a bug. Never replay it at every layer the bug crossed.
• A behavior-preserving refactor should not break the test.

Junk patterns

• Reject self-comparisons, copied inventories, source greps, implementation or call-shape assertions, duplicate contracts, test-only seams, expected values generated by the subject under test, and mocks that supply the behavior being asserted.
• Fixtures must not fabricate receipts or ordering that the owner should produce, and must not claim persistence through a path the code never writes.
• A negative control must fail at the intended guard, and a test's name must match the behavior it actually exercises.
• When auditing candidates, use the full checklist.

Retention bar

• Keep tests that guard independent contracts: public API, SDK, protocol, config, migration, storage, security, platform, defaults, prompt bytes, generated cross-language output, packaging, release, architecture, and observable ordering. Being static or slow does not make a test disposable.
• Source inspection is acceptable only when it survives identifier-only refactors and guards an independent user-facing contract.
• A failing baseline test may be a product bug to repair, not a test to delete.

Audit and validation

• Before any audit edit, read the candidate evidence and workflow. Inspect the full owners, callers, and history, and record what proof remains before deleting anything.
• Delete obsolete production seams together with their tests. Never optimize for deletion counts.
• Do not edit the checkout while a test run is in progress. Run the project's focused test command for the owner and sibling tests, run the project's changed-files checks, then get a review before landing.
• Report the causes, the retained contracts, the proof and its cost, production versus test lines of code changed, and follow-ups. Commit, push, or land only when the task gives you that authority.