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