第5章 手术室：让灯自己亮起来

本章要回答的三个问题：为什么先写红灯、再让它变绿，能倒逼出更好的设计，而不是把工序倒着干？怎么把"测试要写什么"用自然语言表达清楚，让产品和开发用同一种语言对话？一整套灯挂进持续集成流水线之后，为什么绿灯反而可能骗人？

为什么会有这一章

前四章教的是"手动开灯、看灯判断病情"。但一个工程组织要真正从测试里受益，得让灯"自己亮、自动拦、还会报质量账"。这一章就是手术室：先把 TDD 的红-绿-重构循环讲透，它让测试从"事后补"变成"先行牵引"；再用 BDD 把测试语言从代码抽象提到业务场景，解决"测试写了什么连产品都看不懂"的问题；接着讲可测试性设计——很多灯装不上，根子在被测代码本身就不让装；然后把灯全部接进 CI 流水线，提交一次红灯立刻拦截；最后用覆盖率与度量拆穿"灯全绿不等于健康"的幻觉。这一章是全册由"操作"走向"工程治理"的转折。

读完能解决什么

• 能完整走一遍 TDD 的红-绿-重构循环，并说出它为什么依赖"隔离替身"而成立（衔接第 2 章）。
• 能看懂并写出一条 Given-When-Then 的行为描述，让非开发也能读懂测试意图。
• 能识别代码里"难测三件套"（硬编码依赖、静态调用、时间魔数）并用依赖注入等手法改造。
• 能把单元与集成测试分层挂进 CI 流水线，设置合理的自动拦截关卡。
• 能正确读覆盖率报告，区分"行了覆盖"和"行为被验证"，识别虚假绿灯。

各节怎么分工

先决条件

• 完成第 1–4 章，已有单测与集成测试的实操经验。
• 了解版本控制的基本概念（提交、推送、分支）。

往下走到哪

第 5 章把"工程治理"的路铺好，第 6 章则去挑顺手的工具：单元测试框架、Mock 库、集成测试与报告工具。这里学的 TDD、BDD、CI 门槛，都需要落到具体框架和命令上才能兑现，所以第 6 章是第 5 章想法的物理载体。

本章知识点清单

• 能完整走一遍 TDD 的红-绿-重构三步，并解释为什么它依赖"被测代码可隔离"这条前提（回接第 2 章）。
• 能说出 TDD 对胶水代码、探索原型的局限，明白它不是包治百病的仪式。
• 能用 Given-When-Then 句式把一段业务需求翻成一条可测行为，并同时落到单元层与集成层。
• 能分辨"轻量 BDD"与"重量级 BDD 框架"取什么舍什么，不被语法绑架。
• 能识别"硬编码 new、静态调用、时间魔数"三类难测体征，并说明各自破解方向。
• 能把可测试性当作设计质量的一把尺，重申"测不动 ≈ 耦合重、依赖藏得深"。
• 能设计 CI 的分层关卡（提交/合并/发版），把单元与集成灯接到自动亮、红灯自动拦的流水线上。
• 能正确读覆盖率报告，区分"行覆盖"与"行为验证"，识别"高覆盖低验证"的虚假绿灯。

一章一图：让灯自己会亮的自动化链路

这张图把第 5 章的五节排成一条递进的自动化主线：先学会让红灯牵引设计，再让测试会讲业务语言，接着把代码改造成天生好测，然后全部接进 CI 自动拦截，最后用覆盖率这把尺子审视"绿得干不干净"。