7.4 FAQ：十个高频疑问

7.4 FAQ：十个高频疑问

本节摘要：全册收官，把推广 TDD 时被问得最多的十个疑问一次性答清。每问给出立场、依据与对应章节入口；先附一张"情况分流图"，遇到问题时按图索骥比记忆可靠。

问题一：TDD 会不会让调试变多余？

不会，但把调试从主角降成了客串。红灯在编码期抓走的缺陷，正是过去要靠调试器在集成期苦战的那批——调试技能依然值钱，只是出场频率大降。反过来也成立：调试定位出的问题顺手写成复现测试（见问题二），下次它连调试的机会都没有。

问题二：修 bug 要不要先写复现测试？

要，这是性价比最高的 TDD 应用。工序：先写一条复现缺陷的测试（此刻必红，红即证明缺陷存在且可触发）→ 修复实现 → 测试转绿，修复完成。这条测试从此永远驻扎在测试集里，缺陷终身免复发。跳过复现测试直接修，等于修完不验就宣布痊愈。复现测试还有一层别处替代不了的价值：它逼你把缺陷从"偶发的现象"压缩成"确定的条件"——很多所谓诡异的 bug，在写复现测试的过程中就自己现了形，因为写不出复现的人不得不真正理解触发路径，而理解到位的那一刻，修复往往已经浮出水面。

问题三：需求一直变，测试不就白写了？

写错位置的测试才会白写。断言锁行为的测试跟着需求走：行为变了，测试改一行断言，它仍然是你改动的保护网；只有锁实现细节的测试才随重构报废。需求频繁变化恰恰是 TDD 的主场——变化需要结构弹性（第 4 章）与快速回归验证（第 3 章），两者都由测试供给。真正该问的是 1.3 那两个定位问题：需求摇摆到连输入输出都写不出，那就先刺探，别硬写测试。

问题四：拿到需求不知道怎么下第一条断言怎么办？

说明需求还停在"感觉"层。三步拆解：找出名词（对象候选）与动词（行为候选）→ 把动词组成"谁在什么条件下做什么、结果如何"的句子 → 句子直接变测试名。2.3 的三轮演练示范了全过程：从"密码要有点强度"到 test_reject_password_shorter_than_8_chars，中间没有玄学，只有翻译。翻译卡壳还有一种常见情况：动词找到了，但"结果如何"说不清——这其实是个好消息，它暴露的是需求本身的空洞，你恰好在上实现之前发现了它，去找产品经理把"结果"问清楚，比写完实现再返工便宜一个数量级。

问题五：覆盖率目标定多少合适？

不给绝对值，给口径：增量代码覆盖率不得下降、核心模块做变异分数体检、全仓行覆盖只当盲区参考。绝对目标的危害在 7.2 摊开过——数字一挂钩考核，凑数测试立刻繁殖。要硬数字的话，团队约定"新增代码分支覆盖不低于八成"是个务实的起点，且必须配合 7.1 的健康度抽查防止注水。比目标数字更重要的一条配套是免责出口：对确实不值得细测的代码（生成的样板、纯配置），显式豁免并留档——有正当出口的目标才不会被花式绕过，堵死所有出口的目标只会催生精致的假数据。

问题六：遗留代码没有测试，TDD 用得上吗？

用得上，只是工序不同：先织网再动刀（5.2）。接缝手术、特征测试、网内重构三步走完，遗留代码的"可改性"就追平了新代码，之后照常进红绿循环。直接在无测试的旧代码上做 TDD（先写新行为的测试）也常见，但织网一步建议别省——没有基线的改动说不清"变好还是变坏"。

问题七：UI 和前端能 TDD 吗？

分层处理。逻辑层（状态管理、表单校验、数据变换）标准 TDD，毫秒级红灯；组件渲染用快照与组件测试框架覆盖关键形态，反馈也在秒级；像素级的视觉与交互手感不在单元测试射程内（1.3 的另请高明区），交给视觉回归工具与人工验收。把三层混在一锅里谈"前端没法 TDD"，多半是把第三层的困难赖给了第一层。实际项目里还有个务实的过渡法：先把前端组件里的纯函数抽出来（格式化、校验、状态推导），对这部分跑全套循环——抽取本身往往还会显著改善组件的结构，抽完之后组件剩下的渲染逻辑薄到用组件测试即可覆盖。

问题八：mock 用多了到底有什么问题？

三个症状在 3.3 列过：改实现红一片、mock 链穿三层、测试全绿线上出事。本质都是替身越界——替了协议不在你手里的东西，测试开始保护幻觉。解法是收缩：替身退回边界内侧，第三方先包适配层，能换 fake（内存实现）的优先换 fake。自查口诀：替身让你放心的地方多了，还是让你心虚的地方多了？再多给一条渐进式瘦身路径：把最常被替身的两三个协作方换成内存 fake（通常一周工作量），跑一个月看测试维护量——多数团队从此在"该 fake 的地方 fake"上不再需要任何说服。

问题九：测试越写越多，会不会有一天跑不过来？

会，如果不做分层与预算。防线在 5.1 与 6.2：单元层条均一百毫秒预算、超限降层或换替身；慢用例标记隔离，放进流水线晚段；并行与增量执行交给工具。治理还该包括减法：定期删掉重复覆盖的用例——两条测试断言着同一行为时，留下讲得清的那条，另一条是纯粹的运行开销。测试集是资产也需要盘点，只增不减的资产清单迟早失真。测试集变慢是信号不是宿命——它提醒你该治理了，治理手段全在前面章节里。

问题十：团队里就是有人不配合，怎么办？

先分辨不配合的种类：不信（没体验过）走 7.3 的结对与 dojo，制造体验；不会（技能缺口）走 dojo 刻意练习，给学习方法；不愿（价值观抵触）拿 7.2 的结果指标与团队约定谈底线——节律可以商量，红灯挡合并这类底线纪律不商量。最后一条经验：与其花力气改造最后那个抵触者，不如让小队的数据和节奏自然形成同侪压力，人留下还是离开，交给时间。补一句给推动者的宽心话：每个团队里最先信的都是吃过红绿灯甜头的人，你的工作不是说服所有人，而是把第一批甜头送到位——口碑会自己跑起来，比任何强推都快。

还想问

十个问题答完，全册的循环也该转进你的终端了。合上教程，打开编辑器：挑一条手头最小的需求，先写那条注定失败的测试。红——绿——重构，转起来比读进去更重要。