为什么你的”测试驱动”其实是”测试验证”——TDD 这个 Skill 把铁律说透了
写了十几年代码，你真的在「测试」吗？
我见过太多团队把「测试」当成遮羞布——代码写完，补几个测试，调通上线，测试覆盖率刷到 80% 皆大欢喜。但如果你问他们：「你见过测试失败吗？」大多数人会愣住。
这其实是个危险的信号。
先写测试，是信仰还是迷信？
Test-Driven Development 这个 Skill 来自一个叫 Superpowers 的 Agent 开发框架，作者是 obra。整个框架的核心哲学就一句话：
「If you didn’t watch the test fail, you don’t know if it tests the right thing.」
翻译成人话就是：你没亲眼看到测试失败过，就不知道这测试到底在测什么。
TDD 的节奏是 Red → Green → Refactor：
- Red：先写一个会失败的测试，确认它「因为对的原因」失败
- Green：写最少的代码让测试通过，不多不少
- Refactor：清理代码，保持测试全绿
听起来简单？但大多数人的「测试驱动」其实是「测试验证」——代码写完了，跑一下测试，通过了事。测试从第一天起就是绿的，根本没有经历「失败 → 修复」这个认知闭环。
这个 Skill 到底教什么？
Skill 不长，但全是干货：
- 明确「铁律」：没有 Failing Test 就不写生产代码，违反就删掉重写
- 大量对比示例：好测试 vs 坏测试（命名模糊、测 Mock 不测行为、一次测太多东西）
- 各种「合理化借口」清单：包括「代码太简单不用测」「手动测过了」「以后再补」
- Red-Green-Refactor 完整流程图
最狠的是，它把 TDD 的「反直觉」拆得很清楚：为什么测试先通过什么都证明不了？为什么「已经花了 X 小时，删了浪费」是沉没成本谬误？为什么「TDD 太慢」其实是反的？
谁适合用？
如果你：
- 写代码常年不写测试，「以后再补」是口头禅
- 有测试但没见过测试失败，不知道测了个啥
- 想给 AI Coding Agent 植入正经工程纪律（Superpowers 本身就是给 Agent 用的开发框架）
这个 Skill 值得装。它不教测试框架，它教的是测试思维——而这个思维，是大多数国内团队缺失的那块板。
GitHub：https://github.com/obra/superpowers
评论区
0 条评论
登录后可评论。