Back to Details

tdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test-Driven Development

测试驱动开发

When to use

使用场景

  • New logic or behavior
  • Bug fixes
  • Changes that could break existing behavior
  • 新逻辑或行为
  • Bug修复
  • 可能破坏现有行为的变更

Process

流程

  1. Understand the requirement and the relevant code.
  2. Write a failing test for the behavior you want.
  3. Write the minimum code needed to make the test pass.
  4. Simplify the code and tests while they stay green.
  5. Run the full relevant test suite before finishing.
  1. 理解需求及相关代码。
  2. 为所需行为编写一个失败的测试。
  3. 编写让测试通过所需的最少代码。
  4. 在测试保持通过的前提下简化代码和测试。
  5. 完成前运行完整的相关测试套件。

Verification

验证

  • The new behavior has a failing-then-passing test
  • Bug fixes include a reproduction test
  • Tests describe behavior, not implementation details
  • The final test suite passes
  • 新行为有“先失败后通过”的测试
  • Bug修复包含复现测试
  • 测试描述行为而非实现细节
  • 最终测试套件全部通过

Rules

规则

  • Make the smallest safe change that satisfies the failing test.
  • Preserve existing contracts unless the task explicitly changes them.
  • Add tests for failure paths when they matter to the behavior.
  • Do not write implementation code before you have a failing test for the behavior.
  • Skip TDD for documentation, formatting, or non-behavioral scaffolding work.
  • Prefer testing behavior over internals.
  • Use mocks sparingly. Prefer real boundaries when practical.
  • 做出满足失败测试的最小安全变更。
  • 除非任务明确要求，否则保留现有契约。
  • 当失败路径对行为有影响时，为其添加测试。
  • 在针对该行为的失败测试编写完成前，不要编写实现代码。
  • 文档、格式调整或非行为性框架搭建工作无需采用TDD。
  • 优先测试行为而非内部实现。
  • 谨慎使用mock。实际可行时优先使用真实边界。