关于 tdd
这项面向开发者的测试驱动技能适用于存在明确、可行测试路径的 Bug 修复。它优先要求先用聚焦的回归检查复现失败，再验证修复；测试不切实际时则采用其他检查方式。
主要功能
- 01明确预期行为与当前行为
- 02选择范围最小的可行检查
- 03先编写并运行失败测试
- 04通过回归检查验证修复
- 05测试不切实际时采用替代方案
适用场景
- 01修复有明确复现路径的 Bug
- 02新测试不切实际时验证修复
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/tdd确认已加载。
详细介绍
TDD Bug Fix
修复存在明确、低成本测试路径的 Bug 时，应先让错误行为能够通过测试复现，再修改生产代码。目标是编写一项有针对性的回归测试，使其在修复前失败、修复后通过。
如果测试难以切实可行，就不要强行添加测试。如果现有测试需要大规模搭建测试框架、脆弱的模拟对象、缓慢的端到端基础设施、仅生产环境才有的状态、模糊的复现步骤，或大量无关的测试数据变更，就跳过新增测试，改用最贴近问题且有用的验证方式。
工作流
- 理解 Bug。 确认预期行为、当前行为、受影响路径以及最小可观察复现。
- 选择范围最窄的可执行检查。 优先使用该代码路径现有的最贴近的单元、组件、集成或回归测试。如果没有明显可行的测试路径，不要只为满足工作流而从头创建测试。
- 先编写失败测试。 添加能够捕获该 Bug 的最小范围测试。测试应体现预期行为，而不是照搬当前实现。
- 修复前运行新测试。 确认它因预期原因失败。如果测试通过，或因无关原因失败，则先修正测试或复现，再修改实现。
- 修复 Bug。 以最小的生产代码改动满足预期行为，同时保留周边约定。
- 重新运行回归测试。 确认测试现在通过。
如果无法切实编写失败测试
改用最贴近的可执行回归检查：针对性脚本、手动复现命令、浏览器自动化、快照对比、日志断言或范围明确的集成检查。
宁可不添加新测试，也不要写糟糕的测试。糟糕的测试主要是在测试模拟对象、照搬当前实现细节、依赖时序或无关的全局状态、为小改动依赖昂贵的基础设施，或在证明修复后会立即删除。
防护原则
- 不要为了匹配错误的实现而修改测试。
- 除非预期行为确实发生变化且原因明确，否则不要削弱现有断言。
- 让回归测试聚焦于该 Bug。避免大范围修改测试数据或扩展无关覆盖范围。
- 如果 Bug 难以稳定复现，应尽可能让测试具有确定性，并说明要锁定的信号。
- 如果 Bug 暴露出更广泛的一类故障，应先落地有针对性的回归路径，再考虑补充同类覆盖。
最终回复
报告证据，而不只是结果：
- 说明修复前失败的测试或可执行检查，以及它产生的失败结果。
- 说明修复后通过的测试运行，以及执行的其他相关验证。
- 如果无法证明修复前的失败证据，说明原因，并描述所采用的最贴近的回归检查。
评论
支持 Markdown