Test Strategy Designer for Any Feature

What it does

Designs a test strategy for a feature or system, deciding what to test at each level of the testing pyramid. The critical value: it identifies where NOT to test, preventing the common problem of redundant integration tests that duplicate unit test coverage and slow down the build.

The Prompt

Design a test strategy for the following feature/system.

Feature description:
[WHAT THE FEATURE DOES — user-facing behavior, internal logic, integrations involved]

Tech stack:
[LANGUAGE, FRAMEWORK, TEST FRAMEWORK, CI/CD if relevant]

Architecture context:
[KEY COMPONENTS — which services, databases, external APIs are involved in this feature]

Current test situation:
[EXISTING TESTS — "no tests yet" / "unit tests exist for X" / "full test suite with gaps in Y"]

Design a testing strategy:

## 1. Risk Map
Before writing any tests, identify:
- What are the highest-consequence failure modes? (data loss, security breach, billing error, silent corruption)
- What are the highest-likelihood failure modes? (edge cases, integration boundaries, race conditions)
- What changes most frequently in this code? (high churn = high regression risk)
Plot each as: Failure mode → Consequence (HIGH/MED/LOW) × Likelihood (HIGH/MED/LOW) → Test priority

## 2. Test Pyramid Allocation
For each component or behavior, decide the RIGHT test level:

**Unit tests** (fast, isolated):
- List specific functions/methods to unit test
- For each: what inputs, what assertions, why unit-level is sufficient
- Explicitly list what NOT to unit test (e.g., "don't unit test the ORM mapping — the integration test covers it")

**Integration tests** (real dependencies, slower):
- List specific integration boundaries to test (service-to-database, service-to-service, service-to-external-API)
- For each: what the test proves that unit tests cannot
- Test doubles strategy: what to mock vs. what to hit for real, and WHY

**End-to-end tests** (full stack, slowest):
- List only critical user journeys worth E2E coverage (maximum 3-5)
- For each: the specific scenario and why it can't be covered at a lower level
- What to do when E2E tests are flaky (retry policy, quarantine strategy)

## 3. Edge Cases Checklist
Enumerate specific edge cases for THIS feature:
- Boundary values (zero, one, max, overflow)
- Empty/null/missing inputs
- Concurrent access scenarios
- Time-sensitive behavior (timezone, DST, leap year, epoch)
- Unicode / encoding / locale
- Permission boundaries (authorized vs unauthorized)
Assign each to the appropriate test level from section 2.

## 4. Test Data Strategy
- How to generate/maintain test data for each level
- Fixtures, factories, or builders — recommend the approach for this stack
- Database state management (transactions, truncation, seeds)

## 5. What NOT to Test
Explicitly list things that should NOT have dedicated tests:
- Framework behavior (don't test that React renders a div)
- Simple getters/setters with no logic
- Third-party library internals
- Anything already covered by a higher-level test with no additional risk

## 6. CI Integration
- Recommended test execution order in CI
- Parallelization opportunities
- Expected total runtime target
- Failure modes that should block deployment vs. warn

Usage Notes

• The “What NOT to Test” section is as valuable as the testing sections. Over-testing creates slow CI, brittle test suites, and false confidence.
• The risk map prevents the common mistake of testing everything equally. A billing calculation needs exhaustive edge-case coverage; a logging utility does not.
• Provide real architecture context. “We use microservices” tells the model nothing. “OrderService calls PaymentService via gRPC and writes to Postgres” lets it design meaningful integration tests.
• If you already have tests, paste a sample test file so the model can match your conventions (naming, assertion style, setup patterns).
• Pair with the Code Review prompt to review the test code itself — test code has quality standards too.