Test Audit

Test audit

Adapted from openclaw's test-audit skill (MIT, OpenClaw Foundation; see LICENSE).

Judge the result by how much the remaining tests can be trusted, never by how many were deleted. A test is worth keeping when it protects observable behavior, a credible regression, or an independent contract: a public API, protocol, config, migration, storage, security, platform, default, generated, package, release or architecture contract. Static or slow is never a reason to delete.

Scope

Take the user's scope, or the files they name. Read the root and scoped AGENTS.md first; their Tests rule is the bar for every test this audit keeps, rewrites or moves. Leave out skills and code installed from another repository.

Discover, read-only

1. For a broad scope, split it into read-only lanes by owner area and run them in parallel.
2. For each candidate, read the whole test, its production owner, the owner's callers, the overlapping tests, CI routing and history. When a test claims behavior a dependency provides, read that dependency.
3. Prove what a test catches by mutating a scratch copy of its owner and running the test against it, never by editing the checkout.
4. Prefer a few high-confidence candidates over a long speculative list. Report the evidence before editing.

Junk patterns

• Assertion-free coverage probes.
• Self-comparisons and identity copiers.
• Copied fixtures, inventories, manifests or export lists.
• Exact source, import or string greps, and regexes over prose.
• Private predicate or call-shape tests that a test at the real boundary duplicates.
• Duplicate invocations of the same contract, including a test this run just added and a test that builds its own fixture to recheck what a shared fixture already covers.
• Tests whose only purpose is keeping a test-only export, global or wrapper alive.
• Dead production code whose only callers are tests.
• Expected values produced by the helper or renderer under test.
• Mocks that implement the asserted behavior, or one mock standing in for different APIs.
• Fixtures that supply what the owner should produce, or persistence asserted against a store the path never writes.
• Assertions on a value the code returns as a constant.
• Negative controls that pass for an unrelated reason, such as a crash or a denial from a different guard.
• Names or fixtures that promise more than the input exercises.
• Tests coupled to historical documents or plans whose content keeps changing.

Retention bar

Keep a test that independently enforces one of the contracts listed at the top, and keep:

• call ordering when the order is observable behavior;
• a regression with a credible failure mode;
• a source inspection that is the cheapest independent guard, failing when the user-facing key, byte or path changes and surviving an identifier rename; when the project's Tests rule bans source-text tests, the guard moves to its lint or a check script;
• a test that fails on the current tree. Treat it as a possible bug, reproduce it and repair the owner or the fixture instead of deleting it.

A test that resembles the implementation may still be the independent contract. Prove otherwise before removing it.