TDD 工作流

问题：需求还没想清楚就开始堆代码

很多功能在实现阶段才暴露边界和异常路径，返工成本高；测试若只覆盖「能跑」，又容易变成对实现细节的耦合。测试驱动开发（TDD）把可执行规范放在代码之前：先写会失败的测试，再写刚好让测试通过的生产代码，最后在测试全绿的前提下小步重构。

技能如何组织工作流

本技能按 红—绿—重构 周期展开，并强调 TDD 三定律：只为通过失败测试而写生产代码；只写足以暴露失败的测试；只写足以让测试通过的实现。

• 红色阶段：测试必须先失败；用测试名描述期望行为（正常路径、边界、错误状态）；理想情况下每个测试一个断言。
• 绿色阶段：遵循 YAGNI 与「最简单通过」——不提前优化、不写多余代码。
• 重构阶段：在测试保持绿色的前提下处理重复、命名、结构与复杂度；小步改动，改完再提交。

每个测试建议走 AAA：Arrange 准备数据、Act 执行、Assert 验证。技能还给出了测试优先级（正常路径 → 错误 → 边界 → 性能）和常见反模式对照（例如后写测试、测实现而非行为、单测多断言）。

若你在 Agent 场景下协作，可参考 多 Agent 分工：A 写失败测试、B 写最小通过实现、C 负责重构——与人工 TDD 的角色切换一致。

适用边界

| 场景 | 建议 |
|------|------|
| 新功能、Bug 修复、复杂逻辑 | TDD 价值高（修 Bug 可先写复现测试） |
| 探索性开发、UI 布局 | 价值偏低，可先原型再补 TDD |

记住： 若写不出测试，通常说明需求或行为还没讲清楚——测试就是规范。