测试驱动开发
§1摘要与结论
别名：TDD、test-driven development、测试驱动开发、红绿重构、测试先行 | 英文：Test-Driven Development | 类型：方法 / practice
§2局部关系图
§3原理 · 为什么
测试驱动开发把测试从验证工具转变为设计驱动的开发节奏。先写测试意味着在实现之前明确「什么是正确的」：测试成为对期望行为的可执行规格，迫使开发者在编码前想清楚接口、输入与结果，从而减少凭直觉设计带来的返工。红-绿-重构的循环把开发拆成小步：红阶段写出一个必然失败的测试，确认测试本身能捕捉问题并锁定目标；绿阶段用尽可能简单的实现让测试通过，尽快恢复可运行状态；重构阶段在不改变外部行为的前提下改善内部结构，因为此时有测试作为安全网。TDD 的收益不只是测试数量，更在于它带来的自测试代码与短反馈回路：每次改动都能立即知道是否破坏了既有行为，使持续重构与增量设计成为可能。它也是演进式设计的载体，让结构随需求与认知逐步生长，而非在前期一次成型。
§4机制 · 如何运作
TDD 通过交替的失败与通过状态驱动工作。红阶段：编写一个描述下一个待实现小行为的测试并运行，确认它失败——失败是必要的，它证明测试确实在检验尚未实现的逻辑，而不是永远通过的空测试。绿阶段：以能通过测试的最简单实现为目标，避免过早引入未被测试要求的结构，从而防止过度设计；测试通过后系统回到可信状态。重构阶段：在测试保护下消除重复、改善命名与结构，每次只做小改动并保持测试全绿。循环的粒度应尽量小，使每个决策都可验证、可回退。测试本身也是设计反馈：如果写测试时发现构造输入或观察结果异常困难，往往说明被测对象的接口或依赖关系设计不佳，需要在重构阶段调整设计。测试集随循环增长，逐渐成为回归安全网；因此 TDD 与持续集成、重构天然衔接，共同支撑高频、低风险的小步交付。
§5工程 · 怎么落地
实践 TDD 时先建立能够快速运行的测试环境，使单个测试的反馈时间足够短，否则循环无法维持。每个循环只针对一个小行为，测试应聚焦于可观察的外部行为而非内部实现，以便在重构时保持稳定。绿阶段的实现可以朴素乃至刻意简单，先让测试通过，再在重构阶段改善；避免在绿阶段同时引入新行为与结构改动，使失败难以归因。对难以直接测试的依赖，用测试替身或接缝隔离，但应控制替身的使用范围，避免测试与实现细节耦合。对遗留代码，可先在关键路径上建立回归测试，再逐步引入 TDD 节奏，而不是要求全面改造。把测试纳入版本控制与持续集成，让整个团队共享同一套安全网。最后应把 TDD 视为需要练习的工程习惯：代码覆盖率不是目标，短反馈循环与可演进的设计才是；当循环变慢或测试脆弱时，应调整设计或测试策略，而不是放弃循环。团队层面应通过结对、代码评审与共享约定降低 TDD 的学习门槛，使测试先行的节奏成为集体习惯而非个人坚持。
§6权衡卡
因此 TDD 的价值应在完整开发周期中评估，而不应以单个迭代的编码速度来判定其成败。
TDD 并非适用于所有情形，也有明确代价。
其一是学习与节奏成本：坚持小步循环需要纪律与经验，初期往往比直接编码更慢，团队若只看到短期速度下降容易放弃。
其二是测试质量风险：若测试断言实现细节，重构时会产生大量误报，使安全网反而阻碍演进；写不好测试时，TDD 会积累维护负担。
反例之一是把 TDD 等同于高覆盖率，用测试数量衡量效果，产出大量低价值用例。
反例之二是机械执行循环却不在重构阶段改善结构，只得到一堆测试而没有设计改进。
- 其三是不适用于所有问题：探索性问题、算法验证或界面体验等难以预先明确期望结果的任务，先写测试可能抑制探索；对这类问题更适合先做原型再补测试。
- 因此 TDD 应以形成快速反馈与演进式设计为目的，与重构、持续集成配合使用，并在任务性质不适合预写测试时灵活调整，而非教条化执行。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7案例带
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§8信源与核验
核验结论：TDD 的核心是红-绿-重构的小步循环，用测试作为可执行规格与反馈机制来驱动设计；覆盖率只是副产品，追求覆盖率会产出低价值用例并偏离其设计意图 [WEB-026]
§9原始关系清单
展开：本节点的全部原始关系边（2 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依赖关联 | → MTH-I-05 | 测试替身与测试策略 E-492 | TDD 单元循环依赖测试替身隔离依赖 |
| 依据推导 | → ESS-I-01 | 测试作为验证与反馈机制本质 E-487 | TDD 以测试作为快速反馈机制为依据 |