Test Strategy Planning

You are a quality engineering lead. Define a comprehensive test strategy using
the {{approach}} methodology. Balance coverage, confidence, and execution speed
across all layers of the testing pyramid.

## Testing Approach: {{approach}}

### Testing Pyramid (baseline for all approaches)
- **Unit tests** (70%): fast, isolated, deterministic — test one unit of behavior
- **Integration tests** (20%): verify collaboration between components, real DB/services
- **E2E tests** (10%): validate critical user journeys through the full stack

### TDD Workflow (when approach = tdd)
- Red: write a failing test that specifies the desired behavior
- Green: write the minimal code to make the test pass
- Refactor: clean up code while keeping tests green
- Test-first disciplines: write tests before implementation for all new functionality
- Design benefit: TDD forces better API design (if it's hard to test, the design is wrong)
- Commit on green: each commit should have a passing test suite

### BDD Workflow (when approach = bdd)
- Three amigos: developer, tester, product owner define scenarios together
- Gherkin syntax: Given/When/Then for human-readable specifications
- Feature files live alongside code; serve as living documentation
- Step definitions: reusable, composable glue code for scenario steps
- Tools: Cucumber, Behave, Jest-Cucumber, Cypress with cucumber preprocessor

### Traditional Workflow (when approach = traditional)
- Write tests after implementation; use coverage reports to identify gaps
- Test plan document: scope, risk areas, test types, entry/exit criteria
- Prioritize test coverage based on risk: critical paths first

### Unit Test Guidelines
- Follow AAA pattern: Arrange, Act, Assert
- One assertion per test (or closely related assertions)
- Test names describe behavior: `should_return_empty_array_when_no_items_match`
- No test interdependence: each test runs in isolation, any order
- Mock external dependencies: DB, HTTP clients, file system, timers
- Test both happy path and all error paths

### Integration Test Guidelines
- Use real databases (Docker containers via Testcontainers)
- Reset database state between tests: transactions rolled back, or seed + truncate
- Test the integration contract, not the unit logic (that's covered by unit tests)
- Include auth and middleware in integration scope

### Coverage Goals
- Minimum: 80% line coverage on business logic packages
- Critical path coverage: 100% for payment, auth, data deletion flows
- Coverage is a floor, not a ceiling: high coverage with bad tests is false confidence
- Mutation testing (Stryker, mutmut): validate that tests catch actual bugs

### CI Integration
- Run unit tests on every PR (fast, <2 min)
- Run integration tests on every PR (medium, <10 min)
- Run E2E tests on main branch and release candidates only
- Block merge on test failures; flaky tests tracked and fixed within 24h
- Publish coverage report as PR comment; enforce coverage thresholds in CI

### Test Data Management
- Factory functions / builders for test data: flexible, readable setup
- Avoid fixtures for mutable state: they cause order-dependent tests
- Seed scripts for integration/E2E environments

Output: a test plan document outline, example test cases for each layer,
recommended tooling per layer, and CI configuration snippet.

Переменные

Цели экспорта

Используется в паках