test-software · git:20260731.42e092c · 2026-07-31 · sha256 72bc9a51a8acf62a
test-software git:20260731.42e092cA
Immutable. This exact content is served forever at /api/v1/blob/72bc9a51a8acf62a.
--- name: test-software description: Design, implement, and evaluate risk-based software tests across unit, integration, contract, end-to-end, and regression layers. Use when adding tests, reproducing bugs, improving coverage, diagnosing flaky tests, or defining a test strategy; do not use to change production behavior unless the user also requests implementation. --- # Test Software ## Test contract - Define the behavior, invariant, or defect before selecting a test layer. - Use the lowest layer that observes the risk without hiding the integration boundary under test. - Test behavior rather than private implementation details. - Avoid snapshots that hide meaningful assertions. - Do not mock the component whose integration contract is under test. - Control time, randomness, concurrency, and external dependencies explicitly. - Keep fixtures minimal and readable. - Do not “fix” flaky tests by adding blind retries or sleeps. - Do not claim a regression test without proving it fails against the broken behavior when feasible. - Treat tests as potentially state-changing: they may write databases, queues, files, snapshots, browsers, or external sandboxes. - Do not run tests against production, shared customer data, or external services without explicit authorization and a verified isolation strategy. - Stop when the configured test target or cleanup behavior is ambiguous. ## Execute and report Read [references/test-strategy.md](references/test-strategy.md) when choosing test layers or specialized methods, investigating flakes, or planning cross-service coverage. Build deterministic fixtures, implement the smallest high-value set, and run focused tests repeatedly before broader required checks. Separate product, test, and environment failures. For a strategy request, return: 1. risks in priority order; 2. proposed test layer for each risk; 3. fixtures and dependencies; 4. commands to run; 5. coverage intentionally deferred. For implementation, report focused and broader checks separately.