tdd

TDD Bug Fix

修复 bug 时，如果存在清晰且成本低的测试路径，应先让错误行为能够通过测试复现，再修改生产代码。目标是编写一个有针对性的回归测试，使其在修复前失败、修复后通过。

如果测试难以实际实施，就不要勉强添加。如果现有测试需要搭建大量测试框架、使用脆弱的 mock、依赖缓慢的端到端基础设施、依赖仅存在于生产环境的状态、需要模糊的复现步骤，或导致大量无关的测试夹具变更，就跳过新增测试，改用最接近且有用的验证方式。

工作流

1. 理解 bug。 确定预期行为、当前行为、受影响路径，以及最小的可观察复现。
2. 选择范围最窄且可执行的检查。 优先使用该代码路径已有的最接近的单元、组件、集成或回归测试。如果没有明显可行的测试路径，就不要仅为遵循工作流而从头创建测试。
3. 先编写失败的测试。 添加能够捕获该 bug 的最小化定向测试。测试应表达预期行为，而非照搬当前实现。
4. 修复前运行新测试。 确认它因预期原因失败。引用失败内容，而不是断言所在行：异常、与字面值比较时得到空结果，以及预测的不匹配都会显示红色，但只有最后一种能证明测试测量的是该 bug。如果测试通过，或因无关原因失败，应在修改实现前修正测试或复现方式。
5. 修复 bug。 以最小的生产代码改动满足预期行为，同时保留附近的约定。
6. 重新运行回归测试。 确认测试现在通过。

如果无法实际编写失败测试

改用最接近的可执行回归检查：定向脚本、手动复现命令、浏览器自动化、快照对比、日志断言，或有针对性的集成检查。

宁可不添加测试，也不要添加糟糕的测试。糟糕的测试主要是在测试 mock、记录当前实现细节、依赖时序或无关的全局状态、为一个小修复依赖昂贵的基础设施，或在证明修复后就会立即被删除。

守则

• 不要仅为迁就错误的实现而修改测试。
• 除非预期行为确实发生了变化且原因明确，否则不要削弱现有断言。
• 让回归测试聚焦于该 bug。避免大范围修改测试夹具或扩展无关覆盖。
• 如果 bug 表现不稳定，应尽可能让测试保持确定性，并说明测试要锁定的信号。
• 如果 bug 暴露出一类更广泛的故障，应先提交有针对性的回归路径，再考虑增加其他同类覆盖。

最终回复

报告证据，而不只是结果：

• 指出修复前失败的测试或可执行检查，并引用它产生的失败内容；引用应精简到差异部分。
• 指出修复后通过的测试运行，以及执行的任何相关验证。
• 如果无法展示修复前失败的证据，请说明原因，并描述所使用的最接近的回归检查。