Back to Details

tdd-implementation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test-Driven Development

测试驱动开发（Test-Driven Development）

Use a strict red-green-refactor cycle with thin vertical slices.
采用严格的红-绿-重构循环与细粒度垂直切片。

Philosophy

核心理念

Core principle: test behavior through public interfaces, not implementation details.
Good tests:
  • Validate end-to-end behavior through public APIs
  • Read like specifications of capability
  • Survive internal refactors
Bad tests:
  • Mock internal collaborators excessively
  • Assert private methods or internal call order
  • Break when internals change but behavior stays the same
核心原则：通过公共接口（public interfaces）测试行为，而非实现细节。
优质测试：
  • 通过公共API验证端到端行为
  • 可读性强，如同功能规格说明书
  • 在内部重构后仍能正常运行
劣质测试：
  • 过度模拟内部协作对象
  • 断言私有方法或内部调用顺序
  • 当内部实现变更但行为未变时测试失败

Anti-Pattern: Horizontal Slices

反模式：水平切片

Do not write all tests first and all implementation later.
Wrong (horizontal):
RED: test1, test2, test3 GREEN: impl1, impl2, impl3
Right (vertical tracer bullets):
RED->GREEN: test1->impl1 RED->GREEN: test2->impl2 RED->GREEN: test3->impl3
不要先写完所有测试再编写全部实现。
错误示例（水平切片）：
RED: test1, test2, test3 GREEN: impl1, impl2, impl3
正确示例（垂直追踪式开发）：
RED->GREEN: test1->impl1 RED->GREEN: test2->impl2 RED->GREEN: test3->impl3

Workflow

工作流

1. Plan with user

1. 与用户规划

Before writing code:
  • Confirm required public interface changes
  • Confirm priority behaviors to test
  • Identify deep modules (small surface, rich internals)
  • Identify architecture constraints and ADRs in scope
  • Get approval on test plan
Ask:
  • What should the public interface look like?
  • Which behaviors matter most?
编写代码前：
  • 确认所需的公共接口变更
  • 确认需测试的优先级行为
  • 识别深层模块（表面范围小、内部逻辑丰富）
  • 识别范围内的架构约束与架构决策记录（ADRs）
  • 获取测试计划的批准
可询问：
  • 公共接口应该是什么样的？
  • 哪些行为最为关键？

2. First tracer bullet

2. 首个追踪式开发任务

Write one test for one behavior:
RED: write test, confirm it fails. GREEN: write minimal code, confirm it passes.
As soon as the happy-path test is green, add the matching negative-path test for the same behavior (invalid input, rejected state, permission failure, boundary violation, or error path).
针对一个行为编写一个测试：
RED: 编写测试，确认测试失败。 GREEN: 编写最简代码，确认测试通过。
一旦正常路径测试通过，立即为同一行为添加对应的异常路径测试（无效输入、状态被拒绝、权限失败、边界违规或错误路径）。

3. Incremental loop

3. 增量循环

For each remaining behavior:
RED: write next failing test. GREEN: add only enough code to pass.
Rules:
  • One test at a time
  • Cover both positive and negative paths for each behavior before moving on
  • No speculative features
  • Keep assertions on observable behavior only
针对每个剩余行为：
RED: 编写下一个会失败的测试。 GREEN: 仅添加足够让测试通过的代码。
规则：
  • 一次编写一个测试
  • 在进行下一个行为前，覆盖该行为的正常与异常路径
  • 不添加未明确需求的功能
  • 仅对可观察行为进行断言

4. Refactor only on green

4. 仅在测试通过（GREEN）时重构

After tests pass:
  • Remove duplication
  • Deepen modules behind stable interfaces
  • Improve naming and readability
  • Re-run tests after each refactor step
Never refactor while red.
测试通过后：
  • 消除代码重复
  • 在稳定接口后深化模块
  • 提升命名与可读性
  • 每一步重构后重新运行测试
绝不在测试失败（RED）时进行重构。

Tech-Stack Alignment Rules

技术栈适配规则

When implementing each slice:
  • Reuse existing test framework and assertion style in the repo
  • Reuse current package ecosystem (for example npm, NuGet, pip, Maven, Gradle)
  • Follow current architecture and module boundaries
  • Add new dependencies only with explicit justification
实现每个切片时：
  • 复用仓库中已有的测试框架与断言风格
  • 复用当前的包生态系统（例如npm、NuGet、pip、Maven、Gradle）
  • 遵循当前的架构与模块边界
  • 仅在有明确理由时添加新依赖

Per-Cycle Checklist

循环检查清单

  • Test describes behavior, not implementation
  • Test uses public interface only
  • Test would survive internal refactor
  • Code is minimal for current test
  • Positive case is covered for this behavior
  • Negative case is covered for this behavior
  • No speculative or unrelated features added
  • 测试描述的是行为而非实现
  • 测试仅使用公共接口
  • 测试在内部重构后仍能正常运行
  • 代码仅满足当前测试的最简需求
  • 已覆盖该行为的正常场景
  • 已覆盖该行为的异常场景
  • 未添加任何未明确需求或无关的功能