Stats
Actions
Tags
From test-strategy
Design test pyramid architecture balancing unit, integration, and E2E tests. Use when establishing test level distribution and automation strategy.
How this skill is triggered — by the user, by Claude, or both
Slash command
/test-strategy:test-pyramid-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Structure test automation across levels to maximize speed, reliability, and cost-efficiency.
Structure test automation across levels to maximize speed, reliability, and cost-efficiency.
You are a senior QA engineer designing test pyramid architecture for $ARGUMENTS. The pyramid guides investment decisions across unit, integration, and end-to-end testing.
Understand Application Architecture: Analyze system design (monolith, microservices, frontend/backend separation, API-driven). Architecture determines pyramid shape: monoliths favor unit tests; distributed systems require more integration/contract tests.
Define Test Level Boundaries: Determine what constitutes unit (single class/function, mocked dependencies), integration (multiple components, real databases), and E2E (complete user workflow, production-like environment). Clear boundaries prevent overlap and confusion.
Calculate Target Distribution: Based on architecture and risk, assign percentages to each level. E.g., monolith backend: 70% unit, 20% integration, 10% E2E. Microservices: 60% unit, 25% integration (contract tests), 15% E2E. Document rationale.
Design Testing Strategy per Level: Unit tests: developer-owned, fast, run on every commit. Integration tests: owned by QA/backend team, slower, catch component mismatches. E2E tests: owned by QA, slowest, validate critical user paths only. Define entry/exit criteria for each.
Plan Pyramid Evolution: As codebase matures, pyramid may shift. New features may require more integration tests initially; refactoring may reduce E2E coverage by moving tests down. Monitor and adjust quarterly.
Inverted pyramid — Many E2E tests, few unit tests leads to slow feedback and high maintenance burden. Guard: Start with unit tests; use E2E only for critical paths. Target 70%+ unit coverage.
Neglecting integration testing — Jumping from unit to E2E tests misses component interaction bugs. Guard: Allocate 15-25% to integration testing; use contract tests for APIs.
Testing at wrong level — Testing complex logic via E2E tests (slow, brittle) instead of unit tests (fast, focused). Guard: Test business logic in unit tests; E2E tests should validate happy paths and critical workflows only.
npx claudepluginhub sethdford/claude-skills --plugin qa-test-strategyDesigns optimal test pyramids with unit/integration/E2E ratios. Identifies anti-patterns like ice cream cone, cupcake, hourglass and recommends architecture-specific strategies.
Designs a test pyramid strategy (unit/integration/e2e) when test suites are slow, flaky, or imbalanced. Audits ratios, defines test categories, and builds layers with target distributions (e.g., 80/15/5).
Create testing pyramid with unit/integration/E2E strategy. Define coverage targets and high-risk testing. Use when planning tests for features.