Test Strategy

Level Selection Rules

3. Strategy Template

Produce this for every feature or project:

# Test Strategy: {Feature Name}

## Risk Assessment
| Component | Risk Level | Why |
|-----------|-----------|-----|
| {component} | High/Med/Low | {data loss, revenue, security, UX} |

## Coverage Plan
| Layer | Target | What's Covered |
|-------|--------|----------------|
| Unit | {n} tests | {list of modules/functions} |
| Integration | {n} tests | {list of API/DB interactions} |
| E2E | {n} tests | {list of user journeys} |

## Priority Order (implement in this sequence)
1. {highest-risk component} — unit tests
2. {API contracts} — integration tests
3. {critical journey} — E2E test
4. ... remaining by descending risk

## Quality Gates
- [ ] All unit tests pass
- [ ] Integration tests pass with test DB
- [ ] E2E critical path passes
- [ ] Coverage ≥ {target}% on changed files

4. Risk-Based Prioritisation

Not all code deserves equal test investment. Prioritise by risk:

High Risk (test thoroughly)

• Money/payment logic
• Authentication and authorisation
• Data mutations (writes, deletes, migrations)
• External API integrations
• Security-sensitive code (input validation, sanitisation)

Medium Risk (test key paths)

• Business logic with branching conditions
• Data transformations and aggregations
• State management (complex reducers, stores)
• Error handling and recovery

Low Risk (test selectively)

• Display components with no logic
• Configuration files
• Static content
• Simple pass-through functions

5. Coverage Goals

Set coverage targets by component risk, not a blanket number.

6. Test Naming Convention

Every test name answers three questions:

test_{what}_{condition}_{expected_outcome}

Examples:

def test_calculate_discount_with_expired_coupon_returns_zero():
def test_login_with_invalid_password_returns_401():
def test_export_csv_with_empty_dataset_creates_headers_only():

7. When to Update the Strategy

• New risk identified (security audit, incident, production bug)
• Architecture change (new service, DB migration, API version)
• Coverage drops below target on consecutive PRs
• Feature scope expands significantly

8. Anti-Patterns to Avoid

9. Output Artefact

Produce TEST-STRATEGY.md in the project docs or agent-docs directory. Ensure it includes:

1. Risk assessment table
2. Coverage plan with test counts per layer
3. Priority order for implementation
4. Quality gate checklist
5. Named test cases for the top 10 highest-risk areas