| name | Testing Strategy |
| description | Create comprehensive test plans with unit, integration, and E2E test cases |
| version | 1.0 |
| tags | ["engineering","quality","testing"] |
| complexity | intermediate |
| requires_tools | ["mcp:filesystem:*"] |
Process
- Read the code under test — Understand inputs, outputs, and side effects
- Identify test boundaries — What is a unit? What needs integration testing?
- Map test cases — Happy path, edge cases, error cases, boundary values
- Write unit tests — Isolated, fast, mock external dependencies
- Write integration tests — Test component interactions with real dependencies
- Consider E2E scenarios — Full user flows that validate the system end-to-end
- Prioritize — Critical paths first, then edge cases
Output Format
Provide a test matrix:
| Test Name | Type | Input | Expected Output | Priority |
|---|
| test_create_user_success | unit | valid user data | user object returned | P0 |
| test_create_user_duplicate_email | unit | existing email | 409 error | P0 |
| test_user_flow_signup_to_order | e2e | full flow | order created | P1 |
Then provide the actual test code.
Guidelines
- Test behavior, not implementation details
- One assertion per test (or closely related assertions)
- Use descriptive test names that explain the scenario
- Arrange-Act-Assert pattern
- No test interdependencies — each test should be independent
- Mock at boundaries (database, external APIs), not internal functions
- Cover both success and failure paths
- Include edge cases: empty inputs, max values, unicode, concurrent access