tdd

TDD Bug Fix

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

如果测试难以切实可行，就不要强行添加测试。如果现有测试需要大规模搭建测试框架、脆弱的模拟对象、缓慢的端到端基础设施、仅生产环境才有的状态、模糊的复现步骤，或大量无关的测试数据变更，就跳过新增测试，改用最贴近问题且有用的验证方式。

工作流

1. 理解 Bug。 确认预期行为、当前行为、受影响路径以及最小可观察复现。
2. 选择范围最窄的可执行检查。 优先使用该代码路径现有的最贴近的单元、组件、集成或回归测试。如果没有明显可行的测试路径，不要只为满足工作流而从头创建测试。
3. 先编写失败测试。 添加能够捕获该 Bug 的最小范围测试。测试应体现预期行为，而不是照搬当前实现。
4. 修复前运行新测试。 确认它因预期原因失败。如果测试通过，或因无关原因失败，则先修正测试或复现，再修改实现。
5. 修复 Bug。 以最小的生产代码改动满足预期行为，同时保留周边约定。
6. 重新运行回归测试。 确认测试现在通过。

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

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

宁可不添加新测试，也不要写糟糕的测试。糟糕的测试主要是在测试模拟对象、照搬当前实现细节、依赖时序或无关的全局状态、为小改动依赖昂贵的基础设施，或在证明修复后会立即删除。

防护原则

• 不要为了匹配错误的实现而修改测试。
• 除非预期行为确实发生变化且原因明确，否则不要削弱现有断言。
• 让回归测试聚焦于该 Bug。避免大范围修改测试数据或扩展无关覆盖范围。
• 如果 Bug 难以稳定复现，应尽可能让测试具有确定性，并说明要锁定的信号。
• 如果 Bug 暴露出更广泛的一类故障，应先落地有针对性的回归路径，再考虑补充同类覆盖。

最终回复

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

• 说明修复前失败的测试或可执行检查，以及它产生的失败结果。
• 说明修复后通过的测试运行，以及执行的其他相关验证。
• 如果无法证明修复前的失败证据，说明原因，并描述所采用的最贴近的回归检查。