Testing Strategy Pattern

Standard approach for planning tests across different levels.

Test Levels

Unit Tests

Questions to ask:

• What new modules/functions need unit tests?
• What existing tests need updates?
• Are there edge cases or error conditions to cover?

Include in design:

### Unit Tests
- [New modules/functions needing tests]
- [Existing tests needing updates]

Integration Tests (Per-Component)

Questions to ask:

• What component interactions need testing?
• Database or API integration tests needed?
• Are there service boundaries being crossed?

Include in design:

### Integration Tests
- [Component interactions to verify]

End-to-End Tests

Questions to ask:

• Does this feature add new user flows?
• Will it need new scenarios in the E2E test suite?

Include in design:

### E2E Tests
- **Needs update:** Yes / No
- [New scenarios if applicable]

API Compatibility

For features affecting API contracts:

Question	Why It Matters
Could this break existing clients?	Users may not update immediately
Is versioning needed?	Backward compatibility
What's the deprecation path?	How to phase out old behavior

Include in design:

### API Compatibility
- **Existing clients work:** Yes / No
- **Versioning needed:** Yes / No
- [Deprecation path if applicable]

Performance Tests

For performance-sensitive features:

• Any performance-sensitive paths?
• Benchmarks to add or update?
• Are there latency or throughput requirements?

Web UI Testing (if applicable)

For UI changes:

Viewport Testing

• Test at common breakpoints: mobile, tablet, desktop
• Verify layout doesn't break at edge breakpoints
• Check that features work or are intentionally hidden across all sizes

Authentication State Testing

• Test as authenticated user
• Test as unauthenticated user
• Verify feature visibility/behavior is consistent for each auth state

Include in design:

### Web UI Testing
- **Affects authenticated users:** Yes / No
- **Affects unauthenticated users:** Yes / No
- **Responsive behavior:** Consistent / Intentionally different
- **Breakpoints tested:** Mobile / Tablet / Desktop

---

Design-Integrated Testing

When a design includes Key Decisions (ADRs), each decision should map to at least one test that validates correct implementation:

Decision	Test	Expected Outcome
{decision title}	{specific test}	{pass criteria}

This ensures design decisions are not just documented but verified during implementation. The implementation worker should check this table when writing tests.

Test Planning Template

## Testing Strategy

### Unit Tests
- [New modules/functions needing tests]
- [Existing tests needing updates]

### Integration Tests
- [Component interactions to verify]

### E2E Tests
- **Needs update:** Yes / No
- [New scenarios if applicable]

### API Compatibility
- **Existing clients work:** Yes / No
- **Versioning needed:** Yes / No
- [Deprecation path if applicable]

### Web UI Testing (if applicable)
- **Affects authenticated users:** Yes / No
- **Affects unauthenticated users:** Yes / No
- **Responsive behavior:** Consistent / Intentionally different
- **Breakpoints tested:** Mobile / Tablet / Desktop

### Performance Tests
- [If applicable]