TDD Bug Fix 是一个用于缺陷修复的测试驱动开发技能。它的适用条件比较明确：只有当用户明确要求 TDD、失败测试或回归测试，或者当前缺陷存在明显且低成本的本地测试目标时，才应使用；否则应跳过。
用途
当修复一个具有清晰、低成本测试路径的缺陷时，该技能要求在改动生产代码之前，先把损坏的行为变成可执行的测试。目标是得到一个聚焦的回归测试：在修复前失败，在修复后通过。
何时不要强行写测试
如果测试不切实际，就不要强行添加。具体包括：可用的测试需要大范围的测试框架搭建、脆弱的 mock、缓慢的端到端基础设施、仅生产环境才有的状态、模糊的复现步骤，或大量无关的夹具改动。在这些情况下，应跳过新增测试，改用最接近的有效验证方式。
工作流程
- 理解缺陷：识别预期行为、当前行为、受影响的代码路径，以及最小的可观察复现方式。
- 选择最窄的可执行检查：优先使用该代码路径上已有的、最接近的单元测试、组件测试、集成测试或回归测试。如果没有明显可行的测试路径，不要仅仅为了满足流程而从零创建测试。
- 先写失败测试：添加最小的、聚焦的测试，该测试本应能捕获这个缺陷。测试应编码预期行为，而不是镜像当前实现。
- 修复前运行新测试：确认它因预期原因失败。要引用失败内容，而不是断言行——异常、对字面量返回空结果、以及预测的不匹配都会打印红色，只有最后一种才能证明测试确实度量了该缺陷。如果它通过，或因无关原因失败，应先修正测试或复现方式，再编辑实现。
- 修复缺陷：做最小的生产代码改动，满足预期行为，同时保持周边契约不变。
- 重跑回归测试：确认测试现在通过。
如果失败测试不切实际
改用最接近的可执行回归检查：针对性脚本、手动复现命令、浏览器自动化、快照对比、日志断言，或聚焦的集成检查。
宁可没有新测试，也不要坏测试。坏测试指的是：主要测试 mock、编码当前实现细节、依赖时序或无关全局状态、为小修复却需要昂贵基础设施，或在证明修复后会被立即删除的测试。
护栏
- 不要仅仅为了让测试匹配错误实现而修改测试。
- 不要削弱现有断言，除非预期行为确实发生了变化且原因清晰。
- 保持回归测试聚焦于该缺陷，避免大范围夹具改动或无关的覆盖率扩展。
- 如果缺陷是不稳定的，尽量让测试确定化，并记录所锁定的信号。
- 如果缺陷暴露了更广泛的一类失败，先落地聚焦的回归路径，再考虑额外的同类覆盖。
最终回复
报告证据，而不仅仅是结果：
- 指出修复前失败的测试或可执行检查，并引用它产生的失败信息，裁剪到差异部分。
- 指出修复后通过的测试运行，以及所做的任何周边验证。
- 如果无法展示修复前失败证据，说明原因，并描述改用最接近的回归检查是什么。