46 lines
1.6 KiB
Markdown
46 lines
1.6 KiB
Markdown
# Test Strategy
|
|
|
|
## Purpose
|
|
|
|
Choose and evaluate the right level of verification so changes are covered proportionally to their risk, behavior, and maintenance cost.
|
|
|
|
## When to use
|
|
|
|
- Adding or updating tests for a feature or bug fix
|
|
- Deciding what verification is necessary before shipping
|
|
- Auditing coverage gaps in existing code
|
|
- Designing regression protection for risky areas
|
|
|
|
## Inputs to gather
|
|
|
|
- The behavior being changed or protected
|
|
- Current test layout, tooling, and conventions
|
|
- Known failure modes, regressions, or edge cases
|
|
- Constraints on test speed, environment, and confidence needs
|
|
|
|
## How to work
|
|
|
|
- Match test level to risk: unit for logic, integration for boundaries, end-to-end for critical workflows.
|
|
- Prefer the smallest test that meaningfully protects the behavior.
|
|
- Cover success paths, likely failure paths, and regressions suggested by the change.
|
|
- Reuse existing fixtures and patterns where possible.
|
|
- If tests are not feasible, define alternate validation steps and explain the gap.
|
|
|
|
## Output expectations
|
|
|
|
- Specific recommended or implemented tests
|
|
- Clear rationale for test level and scope
|
|
- Any remaining uncovered risks or follow-up test ideas
|
|
|
|
## Quality checklist
|
|
|
|
- Tests target behavior, not implementation trivia.
|
|
- Coverage includes the change's highest-risk paths.
|
|
- Test design fits repository conventions and runtime cost expectations.
|
|
- Non-tested areas are called out explicitly when important.
|
|
|
|
## Handoff notes
|
|
|
|
- Note flaky, expensive, or environment-dependent checks separately from fast local confidence checks.
|
|
- Mention whether the test plan is implemented, recommended, or partially blocked.
|