Testing Strategy

---
name: testing-strategy
description: "Test pyramid, coverage targets, and test patterns (unit/integration/E2E). TRIGGER when: planning tests, writing test code, or reviewing coverage. SKIP: quality-gate scoring of plans (use quality-validation); security testing (use security-review-checklists). (Examples use common runners such as pytest and vitest.)"
---

# Testing Strategy Skill

## Purpose
Comprehensive testing guidelines including test pyramid, coverage targets, and test patterns.

## Auto-Invoke Triggers
- Planning test strategy
- Writing unit/integration tests
- Reviewing test coverage
- Setting up test infrastructure

---

## Test Pyramid

```
        /\
       /  \      E2E Tests (10%)
      /----\     - Critical user flows
     /      \    - Slow, expensive
    /--------\   Integration Tests (20%)
   /          \  - API tests, DB tests
  /------------\ - Medium speed
 /              \ Unit Tests (70%)
/----------------\ - Fast, isolated
                   - Business logic
```

### Distribution Guidelines
| Type | Percentage | Focus |
|------|------------|-------|
| Unit | 70% | Business logic, utilities |
| Integration | 20% | API, database, services |
| E2E | 10% | Critical user journeys |

---

## Coverage Targets

| Metric | Minimum | Target |
|--------|---------|--------|
| Line coverage | 70% | 80% |
| Branch coverage | 60% | 70% |
| Critical paths | 90% | 100% |

### What to Cover
- All public methods
- Business logic
- Edge cases
- Error handling
- Integration points

### What NOT to Cover
- Generated code
- Simple getters/setters
- Framework code
- Third-party libraries

---

## Unit Testing

### Principles
- Test one thing per test
- Tests should be fast (< 100ms)
- Tests should be isolated
- Tests should be deterministic
- No external dependencies

### AAA Pattern
```
Arrange - Set up test data and mocks
Act     - Execute the method under test
Assert  - Verify the expected outcome
```

### Naming Convention
```
{Method}_{Scenario}_{ExpectedResult}

CreateUser_ValidData_ReturnsUserId
CreateUser_DuplicateEmail_ThrowsConflict
CalculateTotal_EmptyCart_ReturnsZero
```

### Test Categories
| Category | Purpose | Example |
|----------|---------|---------|
| Happy path | Normal operation | Valid user creation |
| Edge case | Boundary conditions | Empty input, max length |
| Error case | Failure scenarios | Invalid data, not found |

---

## Integration Testing

### Scope
- API endpoints
- Database operations
- External service calls
- Message queues

### Best Practices
- Use test containers or in-memory DB
- Seed known test data
- Clean up after each test
- Mock external services
- Test full request/response cycle

### API Test Checklist
- [ ] Correct status code
- [ ] Response body structure
- [ ] Headers (content-type, auth)
- [ ] Validation errors
- [ ] Authorization rules

---

## E2E Testing

### When to Use
- Critical user journeys
- Payment flows
- Authentication flows
- Multi-step workflows

### Best Practices
- Test user perspective, not implementation
- Use stable selectors (data-testid)
- Handle async operations properly
- Keep tests independent
- Use page object pattern

### Critical Paths to Test
- User registration/login
- Main feature workflow
- Payment/checkout
- Error recovery flows

---

## Test Data Management

### Strategies
| Strategy | Use Case |
|----------|----------|
| Fixtures | Static test data |
| Factories | Dynamic test data |
| Builders | Complex objects |
| Seeders | Database state |

### Rules
- Use realistic but fake data
- Never use production data
- Reset state between tests
- Use faker libraries for variety

---

## Mocking Guidelines

### When to Mock
- External services (APIs, databases)
- Time-dependent operations
- Random values
- Expensive operations

### When NOT to Mock
- Simple value objects
- The code under test
- Everything (over-mocking)

### Mock Types
| Type | Purpose |
|------|---------|
| Stub | Return canned responses |
| Mock | Verify interactions |
| Spy | Record calls, pass through |
| Fake | Simplified implementation |

---

## Test Organization

### File Structure
```
tests/
├── unit/
│   ├── services/
│   └── utils/
├── integration/
│   ├── api/
│   └── db/
├── e2e/
├── fixtures/
└── conftest.py / setup.ts
```

### Naming
- Test files: `{module}_test.py` or `{module}.test.ts`
- Match source structure
- Group related tests in describe/class

---

## CI/CD Integration

### Pipeline Stages
1. **Unit tests** - Run on every commit
2. **Integration tests** - Run on PR/merge
3. **E2E tests** - Run on deploy to staging

### Quality Gates
| Gate | Requirement |
|------|-------------|
| Unit tests | 100% pass |
| Coverage | > 70% |
| Integration | 100% pass |
| E2E (critical) | 100% pass |

---

## Performance Testing

### Types
| Type | Purpose |
|------|---------|
| Load | Expected traffic |
| Stress | Breaking point |
| Soak | Memory leaks |
| Spike | Sudden traffic |

### Metrics to Measure
- Response time (p50, p95, p99)
- Throughput (requests/second)
- Error rate
- Resource usage

---

## Best Practices

### DO
- Write tests before fixing bugs
- Test behavior, not implementation
- Keep tests simple and readable
- Run tests frequently
- Maintain test code quality
- Use meaningful assertions

### DON'T
- Test private methods directly
- Write flaky tests
- Skip tests temporarily (delete instead)
- Test external systems
- Ignore slow tests
- Copy-paste test code

---

## Test Quality Checklist

- [ ] Tests are fast (< 10s for unit suite)
- [ ] Tests are isolated (no order dependency)
- [ ] Tests are deterministic (no flakiness)
- [ ] Tests are readable (clear intent)
- [ ] Tests cover edge cases
- [ ] Tests verify error handling
- [ ] Mocks are minimal and purposeful
- [ ] CI runs tests automatically