Test Audit

Test Audit

Adapted from OpenClaw's test-audit skill. See NOTICE and LICENSE.

Optimize for confidence, not deletion count. Audit mode discovers a few high-confidence candidates and reports evidence before editing. Authoring mode checks proposed tests at write time. For an explicitly requested whole-subsystem pruning campaign, read CAMPAIGN.md.

Read root and scoped AGENTS.md files and the repository's testing skill and test selection. Those policies govern whether new automation is justified; this skill does not authorize replacement tests, production changes, commits, publication, or deployment. Keep reports and investigation evidence outside the product repository, or in task/PR artifacts.

Authoring gate

Before adding or expanding a test, establish why automation is necessary under the testing policy, then answer:

1. What observable behavior, invariant, or independent contract does it protect?
2. What credible regression makes it fail?
3. Why does existing proof not catch that failure? Each contract has one primary owner at the strongest boundary. Another layer needs a distinct transport, lifecycle, or adapter risk that the owner cannot exercise. Prefer an existing table or fixture to duplication.
4. Does it require a production export, flag, wrapper, or injection hook with no production caller? Exercise the real boundary instead.

A missing answer means the test is not ready. Check every junk pattern below; retain a match only when it independently guards a named contract. Behavior-preserving refactoring should not break a behavior test. A regression must demonstrably fail on the pre-fix owner for the intended reason and pass after the repair. Keep one primary regression at its owner boundary.

Junk patterns

• Assertion-free coverage probes, self-comparisons, and identity copiers.
• Copied fixtures, inventories, manifests, export lists, or schema definitions.
• Exact source, import, or string greps tied to incidental implementation.
• Private predicates or call shapes already exercised at a real boundary.
• Duplicate invocations of a contract, including adapter-local replays of shared helpers.
• Tests that preserve test-only exports, globals, wrappers, or otherwise dead production code.
• Expected values generated by the helper or renderer under test.
• Mocks that implement the asserted behavior, or one identical mock for different APIs.
• Fixtures that supply the receipt, admission, or callback ordering the owner must produce; persistence assertions against a store the production path never writes.
• Capability tests that restate flags rather than exercise promised delivery or acknowledgement.
• Negative controls that pass because of an unrelated guard or unreachable rejection path.
• Names that promise more than the input and assertions exercise.

Discovery and retention

Keep discovery read-only. For broad scope, use independent owner-boundary lanes across core, capabilities/durability, storage, platform adapters, examples, tooling, and cross-cutting patterns. Use an available orchestrate skill when applicable; keep workers read-only with disjoint scopes and one primary integrator.

Before judging a candidate, read the complete test and production owner, entry point, callers, callees, sibling implementations, overlapping tests, CI routing, and relevant history. Inspect dependency source or types when a test claims dependency-backed behavior. Judge what the assertions can detect, not their names, length, citations, or test count.

Keep independent public API, protocol, config, migration, storage, security, platform, default, prompt-byte, generated cross-language, package, release, and architecture contracts when their failure would escape remaining checks and repeatable workflow verification is insufficient. Preserve narrow compile-time inference checks and adapter proof with distinct risks. Observable call ordering and credible regressions can also justify retention.

Source inspection can be the cheapest independent guard when it protects a user-facing key, byte, path, or authority contract and survives identifier-only refactoring. Static or slow is not a deletion reason. A retained baseline failure is a possible product bug: reproduce it and report or repair its owner within scope rather than deleting the test.