聊聊 Superpowers 里的 test-driven-development。
背景
TDD 这套东西是 Kent Beck 在 1990 年代鼓捣出来的。这人是谁？极限编程（Extreme Programming）的创始人，敏捷运动的老前辈。
1999 年他写了《Extreme Programming Explained》，第一次系统聊了这个理念。后来 2003 年又写了《Test Driven Development: By Example》，详细讲怎么落地。
他有一句话挺有名的：
"Code without tests is bad code."
说白了：没有测试的代码，不管你写得多漂亮，我都不敢改。
Superpowers 怎么做的
官方描述：
"Write the test first. Watch it fail. Write minimal code to pass."
就三步。先写测试，跑一下，肯定失败。然后写最少的代码让它过。
核心原则就一句：你没看过测试失败，就不知道它测得到底对不对。
RED-GREEN-REFACTOR
TDD 的核心循环就这么回事：
1. RED — 写个会失败的测试
- 跑一下，确认失败
- 失败原因必须是功能没有，不是拼写错误
2. GREEN — 写最少的代码让它过
- 别贪心，别加测试没让你加的东西
- YAGNI
3. REFACTOR — 重构
- 去重复、改名字、提取函数
- 保持测试一直绿着
然后下一个功能，继续这个循环。
硬核规则
Superpowers 有几条铁律：
"Write code before the test? Delete it. Start over. No exceptions."
翻译：在测试之前写了代码？删掉，重来。没有例外。
什么"留着当参考"、什么"稍微改改"——都不行。看都不能看。
常见借口
| 借口 | 实际情况 |
|---|---|
| "写完再测一样的" | 不一样。测试后写答的是"这干嘛的"，TDD 答的是"这应该干嘛的" |
| "我手工测过了" | 手工测试就是随机应变，没有记录，不能重跑 |
| "删了太浪费" | 沉没成本。留着无法信任的代码才是真正的坑 |
| "我灵活一点不行吗" | TDD 就是最灵活的——在提交前发现 bug 比在生产环境调试快多了 |
什么时候用？
必须用：
- 新功能
- Bug 修复
- 重构
- 行为变更
可以问用户：
- 一次性原型
- 生成代码
- 配置文件
最后
Kent Beck 说过：
"I'm not a great programmer; I'm a programmer with great habits."
我不是什么伟大程序员，我只是个有好习惯的程序员。
TDD 就是这么个习惯。它不是负担，是信心。
Superpowers 把它变成强制流程，AI 也得遵守这个"老派"但管用的开发方式。
