test-plan
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseTest Plan
测试计划
Write a test strategy that answers two questions clearly: what deserves testing and how much testing is enough. Everything else is execution detail.
编写一份能清晰回答两个核心问题的测试策略：哪些内容值得测试以及测试到什么程度才算足够。其余内容均为执行细节。
Step 1: Understand What's Being Tested
步骤1：明确测试对象
Before planning any tests, nail down what you're working with. Read the code or requirements. If the user hasn't provided enough context, ask.
| Input | Question | Watch out for |
|---|---|---|
| Code / Feature | What does this do? What are the inputs and outputs? | Planning tests for code you haven't read |
| Critical paths | Which flows would break the product if they failed? | Treating all code paths as equally important |
| Dependencies | What external systems, APIs, or services does it touch? | Ignoring side effects and integrations |
| Edge cases | What unusual inputs or states could occur? | Only testing the happy path |
If existing tests, specs, or prior conversations exist, pull from them. Don't invent context.
在规划任何测试之前，先明确你要处理的对象。阅读代码或需求文档。如果用户未提供足够上下文，主动询问。
| 输入内容 | 核心问题 | 注意事项 |
|---|---|---|
| 代码/功能 | 它的功能是什么？输入和输出分别是什么？ | 切勿为未阅读过的代码规划测试 |
| 关键路径 | 哪些流程如果失败会导致产品崩溃？ | 不要将所有代码路径视为同等重要 |
| 依赖项 | 它涉及哪些外部系统、API或服务？ | 忽略副作用和集成关系 |
| 边缘场景 | 可能出现哪些异常输入或状态？ | 仅测试正常流程（Happy Path） |
如果已有测试用例、规格说明或前期沟通记录，直接参考这些内容，不要凭空假设上下文。
Step 2: Apply the Testing Pyramid
步骤2：应用Testing Pyramid
Distribute test effort deliberately. The pyramid exists because fast feedback loops matter more than exhaustive simulation.
| Layer | Share | What to test | Characteristics |
|---|---|---|---|
| Unit tests | ~70% | Pure functions, utilities, hooks, reducers, transformers | Fast, isolated, many. Test one thing per test. Mock nothing or mock only external I/O. |
| Integration tests | ~20% | Component interactions, API routes, database queries, service boundaries | Test contracts between units. Verify that pieces work together correctly. Slower, fewer. |
| E2E tests | ~10% | Critical user flows only: signup, checkout, core CRUD | Slow, flaky-prone, expensive. Reserve for flows where failure = revenue loss or user churn. |
These ratios are targets, not rules. A utility library might be 95% unit tests. A UI-heavy app might lean harder on integration tests. Adjust with intent.
合理分配测试精力。Testing Pyramid的存在是因为快速反馈循环比全面模拟更重要。
| 层级 | 占比 | 测试内容 | 特性 |
|---|---|---|---|
| Unit tests | ~70% | 纯函数、工具函数、hooks、reducers、转换器 | 执行速度快、独立隔离、数量多。每个测试仅验证一个功能点。无需Mock或仅Mock外部I/O。 |
| Integration tests | ~20% | 组件交互、API路由、数据库查询、服务边界 | 验证单元间的契约，确保各模块协同工作正常。执行速度较慢、数量较少。 |
| E2E tests | ~10% | 仅针对关键用户流程：注册、结账、核心CRUD操作 | 执行速度慢、易不稳定、成本高。仅用于故障会导致收入损失或用户流失的流程。 |
这些比例是目标而非硬性规则。工具库的测试可能95%都是Unit tests；重UI的应用可能会更依赖Integration tests。根据实际需求调整。
Step 3: Decide What to Test
步骤3：确定测试范围
Map each piece of functionality to the right test type. Use this decision table.
| What you're testing | Test type | Why |
|---|---|---|
| Business logic, calculations, data transforms | Unit test | Fast feedback, easy to cover all branches |
| User-facing flows (form submit, navigation) | Integration or E2E | Need to verify real DOM and event behavior |
| Edge cases (null inputs, empty arrays, boundaries) | Unit test | Cheap to write, high defect-prevention value |
| Visual appearance and layout | Snapshot test (use sparingly) | Brittle; prefer visual regression tools for critical UI |
| API request/response contracts | Integration test | Verify serialization, status codes, error shapes |
| Error handling and failure modes | Unit + integration | Unit for thrown errors, integration for error boundaries and fallback UI |
| State management (stores, reducers) | Unit test | Pure logic, deterministic, fast to test |
| Third-party integrations | Integration test with mocks | Verify your code handles their API correctly |
将每个功能模块对应到合适的测试类型。可参考以下决策表：
| 测试对象 | 测试类型 | 原因 |
|---|---|---|
| 业务逻辑、计算逻辑、数据转换 | Unit test | 反馈速度快，易于覆盖所有分支 |
| 用户端流程（表单提交、导航） | Integration或E2E | 需要验证真实DOM和事件行为 |
| 边缘场景（空输入、空数组、边界值） | Unit test | 编写成本低，缺陷预防价值高 |
| 视觉外观与布局 | Snapshot test（谨慎使用） | 易失效；关键UI优先使用视觉回归工具 |
| API请求/响应契约 | Integration test | 验证序列化、状态码、错误格式 |
| 错误处理与故障模式 | Unit + Integration | Unit测试验证抛出的错误，Integration测试验证错误边界和降级UI |
| 状态管理（stores、reducers） | Unit test | 纯逻辑、确定性强、测试速度快 |
| 第三方集成 | 带Mock的Integration test | 验证你的代码能否正确处理第三方API |
Step 4: Define Coverage Targets
步骤4：定义覆盖率目标
Aim for meaningful coverage, not 100%. Chasing full coverage leads to brittle tests that test implementation details.
| Coverage target | When it makes sense |
|---|---|
| 90%+ | Shared libraries, payment logic, auth flows — code where bugs have outsized impact |
| 70-80% | Application code, feature modules — good balance of safety and velocity |
| 50-70% | Rapidly prototyping, exploratory features — cover critical paths, skip the rest |
| Skip coverage metrics | One-off scripts, throwaway prototypes, generated code |
Focus coverage on:
- Code with high cyclomatic complexity (many branches)
- Code that handles money, auth, or user data
- Code that's changed frequently (high churn = high risk)
追求有意义的覆盖率，而非100%覆盖率。盲目追求全覆盖率会导致测试用例过于脆弱，且仅测试实现细节。
| 覆盖率目标 | 适用场景 |
|---|---|
| 90%+ | 共享库、支付逻辑、认证流程——这些代码出现bug会造成重大影响 |
| 70-80% | 应用代码、功能模块——在安全性与开发速度间取得良好平衡 |
| 50-70% | 快速原型开发、探索性功能——覆盖关键路径，其余部分可跳过 |
| 跳过覆盖率指标 | 一次性脚本、临时原型、生成代码 |
覆盖率应重点关注：
- 圈复杂度高的代码（包含多个分支）
- 处理资金、认证或用户数据的代码
- 频繁变更的代码（变更频率高=风险高）
Step 5: Choose Tools
步骤5：选择测试工具
Pick tools that match your stack. Don't over-engineer the test setup.
| Purpose | Tool | Notes |
|---|---|---|
| Unit tests | Vitest | Fast, ESM-native, Jest-compatible API. Preferred for modern projects. |
| Component tests | Testing Library (@testing-library/react) | Test behavior, not implementation. Queries by role, text, label. |
| User interaction | @testing-library/user-event | Simulates real user events (click, type, tab). Prefer over fireEvent. |
| API mocking | msw (Mock Service Worker) | Intercepts at the network level. Works in tests and browser dev. |
| E2E tests | Playwright | Cross-browser, reliable, good DX. Prefer over Cypress for new projects. |
| Visual regression | Playwright screenshots or Chromatic | Use only for design-critical UI. Not a substitute for functional tests. |
选择与技术栈匹配的工具，不要过度设计测试环境。
| 用途 | 工具 | 说明 |
|---|---|---|
| Unit tests | Vitest | 执行速度快、原生支持ESM、API兼容Jest。是现代项目的首选工具。 |
| 组件测试 | Testing Library (@testing-library/react) | 测试行为而非实现细节。通过角色、文本、标签进行查询。 |
| 用户交互测试 | @testing-library/user-event | 模拟真实用户事件（点击、输入、切换标签）。优先于fireEvent使用。 |
| API Mocking | msw (Mock Service Worker) | 在网络层拦截请求。可用于测试和浏览器开发环境。 |
| E2E tests | Playwright | 跨浏览器、可靠、开发者体验良好。新项目优先于Cypress使用。 |
| 视觉回归测试 | Playwright screenshots 或 Chromatic | 仅用于设计关键的UI。不能替代功能测试。 |
Output Format
输出格式
Deliver the test plan as a prioritized list of test cases grouped by type.
undefined按测试类型分组，以优先级列表的形式交付测试计划。
undefinedTest Plan: [Feature / Component Name]
Test Plan: [Feature / Component Name]
Unit Tests (priority order)
Unit Tests (priority order)
- [function/module] — [what behavior to verify]
- [function/module] — [edge case to cover]
- [function/module] — [what behavior to verify]
- [function/module] — [edge case to cover]
Integration Tests (priority order)
Integration Tests (priority order)
- [interaction/flow] — [what contract to verify]
- [API route] — [request/response shape to verify]
- [interaction/flow] — [what contract to verify]
- [API route] — [request/response shape to verify]
E2E Tests (priority order)
E2E Tests (priority order)
- [critical user flow] — [what end-to-end behavior to verify]
- [critical user flow] — [what end-to-end behavior to verify]
Coverage Notes
Coverage Notes
- Target: [X%] for [reason]
- Skip: [what's deliberately not tested and why]
- Target: [X%] for [reason]
- Skip: [what's deliberately not tested and why]
Open Questions
Open Questions
- [Anything unresolved about test approach]
undefined- [Anything unresolved about test approach]
undefinedAnti-Patterns to Avoid
需要避免的反模式
| Anti-pattern | Problem | Instead |
|---|---|---|
| Testing implementation details | Tests break on every refactor, provide no confidence | Test inputs/outputs and observable behavior |
| Mocking everything | Tests pass but nothing actually works together | Mock only external I/O; let units collaborate |
| Snapshot overuse | Giant snapshots nobody reviews, approved blindly | Use snapshots only for small, stable structures |
| Testing the framework | Verifying that React renders or that Vitest asserts | Test your logic, not the tool's behavior |
| 100% coverage as a goal | Diminishing returns, brittle tests, wasted time | Cover critical paths thoroughly, accept gaps in trivial code |
| Copy-paste test cases | Hard to maintain, masks missing abstractions | Use test.each() or parameterized tests for repetitive cases |
| 反模式 | 问题 | 替代方案 |
|---|---|---|
| 测试实现细节 | 每次重构都会导致测试失败，无法提供有效信心 | 测试输入/输出和可观察行为 |
| 过度Mock | 测试通过但实际模块无法协同工作 | 仅Mock外部I/O；让单元模块自然协作 |
| 过度使用Snapshot | 快照体积过大无人审核，盲目通过 | 仅对小型、稳定的结构使用Snapshot |
| 测试框架本身 | 验证React是否渲染或Vitest是否断言 | 测试你的业务逻辑，而非工具的行为 |
| 以100%覆盖率为目标 | 收益递减、测试用例脆弱、浪费时间 | 全面覆盖关键路径，接受非关键代码的覆盖率缺口 |
| 复制粘贴测试用例 | 难以维护，掩盖缺失的抽象设计 | 对重复场景使用test.each()或参数化测试 |