- name
- test-value
- description
- Improve test value and feedback cost when auditing slow, flaky, redundant or brittle tests; choosing tests during implementation; or reviewing test changes before a commit or PR. Keep ordinary implementation and pre-commit use scoped to the affected behavior, not a repository-wide audit.
- metadata
- internal: true
Test Value
Protect outcomes worth preserving at a cost proportionate to their risk. Test counts, coverage percentages and green runs are evidence, not substitutes for product judgment. When an AI writes both implementation and tests, check whether they share the same mistaken assumption.
Choose the scope
Preserve the user's existing authorization and operational boundaries.
- Audit existing tests: investigate cost, false alarms and protection within the requested scope. An audit request is read-only; an optimization request permits scoped changes. Read audit.md.
- Implementation or pre-commit review: examine the behavior being changed and its affected tests. Decide whether to add, adapt, reuse or remove tests. Reviewing before a commit does not itself authorize committing or pushing.
- Diagnose a failure: identify the outcome the failing check protects, then distinguish a product regression, obsolete assertion, environment failure or unstable test. Keep a narrowly requested fix narrow.
Read decision-examples.md when dealing with automatic-layout snapshots, shared matrices, source assertions, asynchronous waits, test doubles, benchmarks or coverage gaps.
Establish an independent basis for correctness
Explain what must remain true using user requirements, public contracts, compatibility commitments or a real failure. The current implementation and its own generated output cannot, by themselves, establish the correct expectation.
For tests being added or changed, answer three questions in the reasoning or a short change explanation:
- Which concrete mistake would fail this test, and what loss would it cause a user or maintainer?
- Would an equivalent refactor or a better valid result also fail? Which restrictions are actually contractual?
- Which existing test, type check or other check already catches this mistake? Does the additional protection justify its execution and maintenance cost?
Prefer observable output, state, data integrity and failure behavior. Private-function tests, snapshots and static checks can also protect real boundaries; their form alone does not determine their value.