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 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:
- risks in priority order;
- proposed test layer for each risk;
- fixtures and dependencies;
- commands to run;
- coverage intentionally deferred.
For implementation, report focused and broader checks separately.