Superpowers TDD实践一次跑通完整的RED-GREEN-REFACTOR循环【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers修bug最怕的就是这一下改好了那一下又改出个新的。测试驱动开发TDD就是为防这件事而生的。本文拿 Superpowers 项目的真实约定带你完整走一遍 RED-GREEN-REFACTOR 循环怎么写一个预期失败的测试、怎么写刚好通过的代码、怎么安全地改代码再附上三类常见场景、常见 TDD 误区以及一份 TDD 新手教程级的动手指南。什么是RED-GREEN-REFACTOR一句话看懂TDD的铁律一句话版本先写测试看着它失败再写刚好让它通过的代码最后在不改变行为的前提下改代码。三步走完就是一个 TDD 循环RED — 写失败的测试把功能该有的行为先说清楚此时功能还没实现测试必须失败GREEN — 写最小实现不优化、不考虑扩展性只求把测试变绿REFACTOR — 改结构保行为测试是安全网此时整理代码行为一点不能变Superpowers 对此定了条铁律没有失败的测试就不要编写生产代码。写不出测试说明你还没想清楚要做什么。一次完整TDD循环走查拿金额校验举例我们来完整过一遍。假设需求是下单金额不允许为负数。第一步RED写一个必须失败的测试先用测试语言把期望行为描述出来test(rejects a negative amount, () { const result checkAmount(-10); expect(result.error).toBe(Amount cannot be negative); });按项目约定测试文件命名为test-skill-name.sh放在测试脚本目录下。跑一次npm test path/to/test.test.ts它必须失败——因为checkAmount还不存在。如果不失败说明测试本身有问题先修测试。第二步GREEN写刚好通过的代码只写让测试通过的最少代码多一行都不写function checkAmount(value: number) { if (value 0) { return { error: Amount cannot be negative }; } return { ok: true }; }再跑一次npm test path/to/test.test.ts这次变绿 。注意测试没要求金额上限这里就别加那叫过度设计。第三步REFACTOR改结构保行为有了测试垫底现在改代码是安全的。比如把校验规则抽成配置方便以后加新规则const rules [ { test: (v: number) v 0, message: Amount cannot be negative }, ]; function checkAmount(value: number) { for (const rule of rules) { if (rule.test(value)) return { error: rule.message }; } return { ok: true }; }跑一遍测试必须全部保持绿色。一旦变红立刻停下回滚不许顺手继续改。三类常见场景新功能、修bug、重构同一个循环场景不同只是起点不同开发新功能从期望行为出发。先把想调用的 API 写成测试断言写得出来设计就基本成型了修bug第一步是写一个能复现 bug 的测试RED。举个例子如果0被误判成非法金额就先写一条0 是合法金额的测试确认它失败再修判断逻辑让它变绿最后整理代码。复现测试写不出来通常说明你还没看懂这个 bug重构前提是测试本来就在通过。改命名、抽函数、消重复因为行为不变所以每一步都是安全的容易踩的坑测试怎么写得出来、又干净下面几问几答是实际操作时最常遇到的情况不知道怎么测先把你期望的 API 和断言语句写出来实在写不出来找同事聊——往往会发现是设计本身要改测试复杂到读不懂复杂的测试常常是复杂设计的信号回去简化设计是不是所有依赖都得模拟优先用依赖注入降低耦合模拟只在必要时用测试尽量走真实代码铺垫代码太厚抽成辅助函数抽完还厚说明设计已经过大了测试名起得含糊名字要描述行为test(test1)这种是不允许的一个测试只验证一件事名字里出现和就该拆测到了实现细节只关注它做了什么不关注它怎么做的——测行为不测代码结构在Superpowers中三步开始TDD实践先克隆仓库git clone https://gitcode.com/GitHub_Trending/su/superpowers然后读一遍 TDD技能文档把三个阶段的循环要求和测试质量原则弄清楚。最后挑一个小功能完整走一遍 RED-GREEN-REFACTOR再跑测试脚本确认cd tests/claude-code ./run-skill-tests.sh其中 run-skill-tests.sh 是批量执行技能测试的入口写测试时可以直接复用 test-helpers.sh 里的公共辅助函数想看现有案例参考 test-subagent-driven-development.sh。提交前自查清单每个新函数/方法都有对应的测试实现之前亲眼看到过测试失败而不是想当然认为它会失败失败的原因是功能缺失而不是拼写、语法错误写的是刚好能通过测试的最少代码所有测试通过输出干净、无错误和警告测试尽量使用真实代码模拟只出现在必要时边缘情况和错误处理都已覆盖有一条勾不上就说明流程跑偏了——推倒重来比事后修补更快。TDD 不是形式主义的步骤而是先想清楚再动手的思维方式下次动手写生产代码前先问一句那个失败的测试写好了吗【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Superpowers TDD实践：一次跑通完整的RED-GREEN-REFACTOR循环
Superpowers TDD实践一次跑通完整的RED-GREEN-REFACTOR循环【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers修bug最怕的就是这一下改好了那一下又改出个新的。测试驱动开发TDD就是为防这件事而生的。本文拿 Superpowers 项目的真实约定带你完整走一遍 RED-GREEN-REFACTOR 循环怎么写一个预期失败的测试、怎么写刚好通过的代码、怎么安全地改代码再附上三类常见场景、常见 TDD 误区以及一份 TDD 新手教程级的动手指南。什么是RED-GREEN-REFACTOR一句话看懂TDD的铁律一句话版本先写测试看着它失败再写刚好让它通过的代码最后在不改变行为的前提下改代码。三步走完就是一个 TDD 循环RED — 写失败的测试把功能该有的行为先说清楚此时功能还没实现测试必须失败GREEN — 写最小实现不优化、不考虑扩展性只求把测试变绿REFACTOR — 改结构保行为测试是安全网此时整理代码行为一点不能变Superpowers 对此定了条铁律没有失败的测试就不要编写生产代码。写不出测试说明你还没想清楚要做什么。一次完整TDD循环走查拿金额校验举例我们来完整过一遍。假设需求是下单金额不允许为负数。第一步RED写一个必须失败的测试先用测试语言把期望行为描述出来test(rejects a negative amount, () { const result checkAmount(-10); expect(result.error).toBe(Amount cannot be negative); });按项目约定测试文件命名为test-skill-name.sh放在测试脚本目录下。跑一次npm test path/to/test.test.ts它必须失败——因为checkAmount还不存在。如果不失败说明测试本身有问题先修测试。第二步GREEN写刚好通过的代码只写让测试通过的最少代码多一行都不写function checkAmount(value: number) { if (value 0) { return { error: Amount cannot be negative }; } return { ok: true }; }再跑一次npm test path/to/test.test.ts这次变绿 。注意测试没要求金额上限这里就别加那叫过度设计。第三步REFACTOR改结构保行为有了测试垫底现在改代码是安全的。比如把校验规则抽成配置方便以后加新规则const rules [ { test: (v: number) v 0, message: Amount cannot be negative }, ]; function checkAmount(value: number) { for (const rule of rules) { if (rule.test(value)) return { error: rule.message }; } return { ok: true }; }跑一遍测试必须全部保持绿色。一旦变红立刻停下回滚不许顺手继续改。三类常见场景新功能、修bug、重构同一个循环场景不同只是起点不同开发新功能从期望行为出发。先把想调用的 API 写成测试断言写得出来设计就基本成型了修bug第一步是写一个能复现 bug 的测试RED。举个例子如果0被误判成非法金额就先写一条0 是合法金额的测试确认它失败再修判断逻辑让它变绿最后整理代码。复现测试写不出来通常说明你还没看懂这个 bug重构前提是测试本来就在通过。改命名、抽函数、消重复因为行为不变所以每一步都是安全的容易踩的坑测试怎么写得出来、又干净下面几问几答是实际操作时最常遇到的情况不知道怎么测先把你期望的 API 和断言语句写出来实在写不出来找同事聊——往往会发现是设计本身要改测试复杂到读不懂复杂的测试常常是复杂设计的信号回去简化设计是不是所有依赖都得模拟优先用依赖注入降低耦合模拟只在必要时用测试尽量走真实代码铺垫代码太厚抽成辅助函数抽完还厚说明设计已经过大了测试名起得含糊名字要描述行为test(test1)这种是不允许的一个测试只验证一件事名字里出现和就该拆测到了实现细节只关注它做了什么不关注它怎么做的——测行为不测代码结构在Superpowers中三步开始TDD实践先克隆仓库git clone https://gitcode.com/GitHub_Trending/su/superpowers然后读一遍 TDD技能文档把三个阶段的循环要求和测试质量原则弄清楚。最后挑一个小功能完整走一遍 RED-GREEN-REFACTOR再跑测试脚本确认cd tests/claude-code ./run-skill-tests.sh其中 run-skill-tests.sh 是批量执行技能测试的入口写测试时可以直接复用 test-helpers.sh 里的公共辅助函数想看现有案例参考 test-subagent-driven-development.sh。提交前自查清单每个新函数/方法都有对应的测试实现之前亲眼看到过测试失败而不是想当然认为它会失败失败的原因是功能缺失而不是拼写、语法错误写的是刚好能通过测试的最少代码所有测试通过输出干净、无错误和警告测试尽量使用真实代码模拟只出现在必要时边缘情况和错误处理都已覆盖有一条勾不上就说明流程跑偏了——推倒重来比事后修补更快。TDD 不是形式主义的步骤而是先想清楚再动手的思维方式下次动手写生产代码前先问一句那个失败的测试写好了吗【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考