菜单
Design test pyramid architecture balancing unit, integration, and E2E tests. Use when establishing test level distribution and automation strategy.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/sethdford/claude-skills --skill test-pyramid-design命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Identify and avoid common architectural mistakes. Recognize patterns of failure. Use when reviewing designs or learning from mistakes.
Practice architectural design with structured problems. Time-limited design challenges. Use for skill development, interviews, team exercises.
Reference catalog of proven architecture patterns. Know when to apply each pattern, tradeoffs, and examples. Use as reference when designing systems.
基于 SOC 职业分类
正在显示 SKILL.md
| name | test-pyramid-design |
| description | Design test pyramid architecture balancing unit, integration, and E2E tests. Use when establishing test level distribution and automation strategy. |
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.
