Design test pyramid architecture balancing unit, integration, and E2E tests. Use when establishing test level distribution and automation strategy.
From test-strategynpx claudepluginhub sethdford/claude-skills --plugin qa-test-strategyThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
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.