测试驱动开发（TDD）

先写测试，看它失败，再写最少代码让它通过。

核心： 若没见过测试 失败，就不知道它是否真的测到了该测的东西。
违反流程细节 = 违反 TDD 精神。

何时使用

总是： 新功能、修 Bug、重构、行为变更。
例外： 一次性原型、生成代码、纯配置——需 协作者 明确同意。
想「就这一次跳过」→ 几乎一定是自我合理化。

铁律

没有先失败的测试，就不能写生产代码。

若先写了实现代码 → 删掉，重来。不要留作「参考」、不要边写测边「改编」、不要偷看——删就是删，再按测试从零实现。

红—绿—重构

1. 红：写一个 最小 测试描述期望行为；命名清晰、测真实行为、尽量不用无谓 mock。
2. 验证红：必须 跑测试，确认 失败方式正确（缺功能而非笔误）。若已通过 → 测试没测到新行为，重写测试。
3. 绿：写 最少 代码让测试通过；不夹带未测功能、不大重构。
4. 验证绿：必须 再跑，全绿、无多余告警。
5. 重构：仅在绿的前提下整理结构，不加行为。
6. 重复下一行为。

好测试

小：一个行为；名字里出现「且」就拆分。
清：名字说明行为。
表意：展示期望的 API 用法。

为何顺序不能反

「写完再补测」→ 测一上来就绿，什么也证明不了（可能测错对象、测实现细节、漏边界）。
「我手动都试过了」→ 不可重复、无记录、压力下易漏。
「删了几小时代码可惜」→ 沉没成本；留着不可信代码才是债。
「TDD 教条，我务实」→ TDD 就是 务实：早失败、防回归、可重构、文档即测试。

危险想法表

太简单不测、写完再测、测后一样、手动够了、留着参考、先探索再…、测试难写=设计难用、TDD 慢、只此一次… → 统统视为该删实现重来。

Bug 修复示例（逻辑）

红：写复现 Bug 的断言 → 跑，见预期失败 → 绿：最小修复 → 再跑全绿 → 重构若有需要。

完成前自检

• 新函数都有测试
• 每个 测试都见过失败再实现
• 失败原因符合预期（缺功能非 typo）
• 实现最简、全绿、输出干净
• 尽量真实代码少 mock
• 边界与错误路径覆盖

卡住时

不会写测试 → 先写理想 API/断言或问协作者。测试太复杂 → 设计可能太复杂。全靠 mock → 耦合过高，考虑注入依赖。setup 太大 → 抽辅助或简化设计。

与调试衔接

发现 Bug：先写失败测试 再走 TDD 循环；无测试的修复不接受。

反模式

见 @testing-anti-patterns.md：测 mock 行为、生产代码里塞 test-only 方法、不理解依赖就 mock。

最后

生产代码 ⟺ 存在且先失败过的测试
否则 ⟺ 不是 TDD

无协作者特许，不设例外。