tdd-workflow

TDD 工作流

严谨地遵循红 → 绿 → 重构循环。每次只处理一个失败的测试，用最少的代码使其通过，然后在测试全绿的前提下重构。这是一种方法论技能——严格遵循循环；不要批量处理。

适用场景

当行为可以用断言表达时使用：业务逻辑、解析器、API、算法、错误修复（先编写失败的测试来复现问题）。临时验证、纯 UI 布局或没有维护计划的探索性原型不适用。

循环

RED — 编写一个失败的测试

• 选择最小的未明确行为。
• 编写一个测试来断言该行为。运行测试。确认它因正确的原因失败（断言失败，而非导入或语法错误）。
• 立即通过的测试，或因拼写错误而失败的测试，都不算红。修正后重新运行。

GREEN — 编写使测试通过的最少代码

• 编写能使该测试通过的最少代码——此时可以硬编码。
• 运行完整的测试套件，而不仅仅是新测试。全绿意味着全部通过。
• 不要“顺手”添加未经测试的代码。如果需要添加，就必须先编写测试 → 回到 RED。

REFACTOR — 在全绿时改进代码

• 消除重复、明确命名、简化结构。
• 每次修改后都重新运行完整的测试套件。任何测试变红 → 撤销重构，不要继续调试。
• 此阶段不改变行为。新行为需要一个新的 RED。

重复此过程，直到功能的所有行为都得到覆盖。

设置

检测项目现有的测试运行器——不要引入新的运行器。

# JS/TS:  npx vitest run   |  npx jest
# Python: pytest -q
# Go:     go test ./...
# Rust:   cargo test

如果不存在测试框架，请在开始前询问要添加哪个；选择符合该生态系统默认配置的框架。

错误修复模式

1. RED：编写一个复现问题并失败的测试。
2. GREEN：持续修复，直到测试通过且没有其他问题。
3. 保留复现测试，作为回归保护。

绝不要在没有证明问题确实存在的失败测试时修复错误。

测试质量

• 每个测试只验证一种行为；测试名称应说明该行为。
• 断言可观察到的结果，而非内部调用，除非交互本身就是约定。
• 将边界情况分别作为 RED 覆盖：空值、边界、无效输入、异步失败、并发。
• 如果破坏代码也无法让测试失败，那么该测试毫无作用——删除或修正它。

反模式

• 先编写实现，再编写与之匹配的测试（这不是 TDD）。
• 先编写 10 个测试再实现——这会失去设计反馈。
• 跳过“确认测试失败”这一步。
• 在同一步中同时重构和添加行为。
• 过度使用模拟，导致真实代码损坏时测试仍然通过。

完成标准

所有行为都有先失败后通过的测试，完整测试套件全绿，没有未经测试的生产代码，并保留错误修复测试作为回归覆盖。