tdd

TDD 缺陷修复

修复存在清晰且成本低廉的测试路径的缺陷时，应先让错误行为能够通过测试复现，再修改生产代码。目标是编写聚焦的回归测试，使其在修复前失败、修复后通过。

不要在测试不切实际时强行编写测试。如果现有测试需要大范围搭建测试框架、脆弱的模拟、缓慢的端到端基础设施、仅生产环境才有的状态、含糊的复现步骤，或大量无关的测试夹具改动，请跳过新增测试，改用最贴近问题且有用的验证方式。

工作流程

1. 理解缺陷。 确定预期行为、当前行为、受影响的路径，以及最小可观察复现。
2. 选择范围最窄且可执行的检查。 优先使用该代码路径已有的最贴近的单元、组件、集成或回归测试。如果没有显而易见且切实可行的测试路径，不要为了满足工作流程而从头创建测试。
3. 先编写失败的测试。 添加能够发现该缺陷的最小聚焦测试。测试应体现预期行为，而不是照搬当前实现。
4. 修复前运行新测试。 确认测试因预期原因而失败。如果测试通过，或因无关原因而失败，应先修正测试或复现方式，再修改实现。
5. 修复缺陷。 在保留相邻约定的前提下，进行满足预期行为所需的最小生产代码改动。
6. 重新运行回归测试。 确认测试现在能够通过。
7. 运行相邻验证。 当改动风险较大时，运行相关的相邻测试、类型检查、lint 或场景检查。

无法实际编写失败测试时

不要悄无声息地跳过回归步骤。修复前，应明确说明无法编写失败测试的原因，或说明其成本不值得，然后选择最接近且可执行的回归检查。示例包括定向脚本、手动复现命令、浏览器自动化、快照对比、日志断言或聚焦的集成检查。

宁可不新增测试，也不要编写糟糕的测试。糟糕的测试是指主要在测试模拟、记录当前实现细节、依赖时序或无关的全局状态、为一个小修复依赖昂贵的基础设施，或在证明修复有效后会立刻被删除的测试。

防护原则

• 不要仅为适配错误的实现而修改测试。
• 除非预期行为确实发生了变化且原因明确，否则不要削弱现有断言。
• 让回归测试聚焦于该缺陷；避免大范围改动测试夹具或扩展无关的覆盖范围。
• 实际验证效果较弱时，不要添加测试；改用手动或脚本验证，并说明原因。
• 如果缺陷不稳定，尽可能让测试保持确定性，并记录要锁定的验证信号。
• 如果该缺陷暴露了更广泛的一类故障，先提交聚焦的回归测试路径，再考虑补充其他同类覆盖。

最终回复

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

• 指明修复前失败的测试或可执行检查，以及它产生的失败。
• 指明修复后通过的测试运行，以及执行过的相邻验证。
• 如果无法展示修复前失败的证据，请说明原因，并描述所用的最接近的回归检查。