第4章 红绿灯分诊台：单元与集成的分工与取舍

本章要回答的三个问题：单元测试和集成测试到底差在哪几个关键维度，为什么这些差异决定了一家公司的测试体感？同一段需求，我该用哪一层灯去照它？这两层灯是互相浪费还是互为保险？

为什么会有这一章

前面两章各修各的灯，那只是单项体检和拼装会诊的两种手艺。可现实中你面对的不是"要不要单测"或"要不要集成测试"，而是"这个功能该在哪层补测试、补多少、零散还是整体"。答错了很痛：有人攒了一万条单元测试，接口一改全崩，才发现大量测试在验证实现细节而非行为；有人把什么都塞进集成测试，一个用例跑三十秒，团队改个字段就集体喝咖啡等构建。这一章就是急诊科的分诊台：把两种灯放到同一张表上比，告诉你差异到底埋在哪几个旋钮上，再给一套"按代码距离和风险来选层"的判断框架，最后讲清楚二者如何像锁和钥匙一样互补。

读完能解决什么

• 能在速度、隔离、成本、缺陷定位四个维度上，快速说出两种测试各自的长短板。
• 能用一个"被测代码离外部世界近不近"的标尺，判断一段逻辑归单元层还是集成层。
• 能解释"避免重复测试"的真正含义——不让单元层和集成层翻同一个波澜，而是分头守住风险。
• 会组装一条"单元快筛 + 集成深检"的分层防线，而不是二选一。
• 能在排期和覆盖率冲突时，做出有依据的取舍，而不是拍脑袋。

各节怎么分工

先决条件

• 完成第 2、3 章，对两种测试的实操手感已建立。
• 能画出一张简单的组件依赖图（谁调谁）。

往下走到哪

第 4 章告诉你灯怎么分工，第 5 章再往上走一层：不再手动开灯，而是让灯在自己会亮（TDD 让红灯先行）、用语义更清晰的 BDD 描述行为、让代码天生好测（可测试性设计）、把所有灯接进 CI 流水线自动拦截，最后用覆盖率这把尺子审视"灯全绿 ≈ 健康吗"。第 4 章是战术，第 5 章是战略。

本章知识点清单

• 能在速度、隔离、成本、缺陷定位、数量与维护成本六个维度上，快速说出单元与集成测试各自的档位。
• 能解释"单件体检 vs 拼装会诊"不是等级差异而是分工差异，并举出各自适用的场景实例。
• 能用"离外部世界距离 + 风险尖点"两步法，把一段具体需求分到单元层或集成层。
• 能识读一个"近远 × 风险高低"的四宫格，并针对四格给出不同的投入策略。
• 能解释"避免重复测试"的正确含义——每层只验自己能验的一半真，不越界也不漏界。
• 能从提交、合并、发版三级视角，把单元与集成测试布成一条分层防线并给出频次。
• 能把两层结果合并成一页看板状态，让"整条链路是否都亮绿灯"可跟踪而非靠感觉。

一章一图：盖到这层灯的分诊逻辑

这张图把 4.2 节的两步判定浓缩成一次公开分诊：先量距离，再看风险尖点，两个问号各走一头，最终灯落的位置就有了根据。后面 4.1 的对照表、4.2 的矩阵、4.3 的布线图，都是绕着这张分诊图转的三个具体切口。把这张图放进脑子，第 4 章的三节就合成了一条可随时调用的决策线——以后每接到一段新逻辑，都能顺着这张图快速走一遍，得出"该归哪层、该下多重"的结论，而不必每次从头翻菜谱。