关于 ds-tdd
ds-tdd 是一项指导编码 Agent 以测试驱动方式修复缺陷的技能，先复现问题，再验证修复和周边测试。
主要功能
- 01先明确并复现缺陷
- 02沿用现有测试风格
- 03修复前运行测试并确认失败
- 04验证修复及周边测试
- 05测试不适用时改用可运行检查
适用场景
- 01为已报告的缺陷编写回归测试
- 02确认失败由缺陷而非测试错误导致
- 03验证小幅生产代码改动
- 04测试环境不适用时检查复现脚本或日志
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/ds-tdd确认已加载。
详细介绍
ds-tdd
在修改生产代码之前，先让 bug 能通过测试复现，这样才能证明修复有效，而不是只做口头保证。
步骤
- 明确 bug：预期行为、实际行为、代码路径，以及最小复现方式。
- 找到该代码路径最接近的现有测试风格，并沿用它。不要专门为此搭建新的测试框架。
- 编写能够捕获该 bug 的最小测试。测试应检查预期行为，而非当前实现。
- 运行测试并展示输出。测试必须失败，而且必须是因为该 bug 失败，而不是因为拼写错误或缺少导入。如果不是，先修正测试。
- 做出能实现预期行为、又不破坏相邻契约的最小生产代码改动。
- 运行新测试和相关测试套件，并展示输出。
- 如果难以进行干净的测试（需要繁重的设置、模拟不稳定，或依赖仅在生产环境存在的状态），就使用最接近且可运行的检查：脚本、复现命令或日志检查。说明跳过测试的原因。
停止条件
- 新测试在修复前失败、修复后通过，并展示了两次运行的输出；相关测试套件也通过。
- 或者经过三次修复尝试后，测试仍然失败。此时停止，报告你了解到的情况，并运行 /ds-unstick。
规则
- 绝不修改测试来迎合错误的实现。
- 除非理由明确且已说明，否则不要弱化现有断言。
- 测试胜过没有测试，但糟糕的测试不如不测：例如主要测试模拟对象、依赖时序，或之后会被删除的测试。
评论
支持 Markdown