# 常见借口 vs 现实

## 完整对照表

| 借口 | 现实 | 正确做法 |
|--------|---------|----------|
| "太简单了不需要测试" | 简单的代码也会崩溃。测试需要 30 秒。 | 写测试，保护未来。 |
| "我之后会测试" | 测试立即通过证明不了什么。可能测试错误的东西。 | 先写测试，看它失败。 |
| "测试后达到相同目标" | 测试后 = "这是做什么？" 测试前 = "这应该做什么？" | 测试前写，证明它测试了正确的东西。 |
| "已经手动测试了" | 临时 ≠ 系统。没有记录，无法重新运行。 | 自动化测试，可以重复运行。 |
| "删除 X 小时是浪费" | 沉没成本谬误。保留未验证的代码是技术债务。 | 删除，从 TDD 重新开始。 |
| "保留作为参考，先写测试" | 你会改编它。那是测试后。 | 删除意味着删除，不看它。 |
| "需要先探索" | 可以。扔掉探索，从 TDD 开始。 | 探索 → 删除 → TDD。 |
| "测试很难 = 设计不清晰" | 听测试。难测试 = 难用。 | 简化接口，让测试变简单。 |
| "TDD 会拖慢我" | TDD 比调试快。务实 = 测试优先。 | 花 30 秒写测试，省 3 小时调试。 |
| "手动测试更快" | 手动不能证明边界情况。每次更改你都会重新测试。 | 自动化，一次编写，终身受益。 |
| "现有代码没有测试" | 你在改进它。为现有代码添加测试。 | 改进代码，添加测试。 |
| "测试太难写" | 设计可能有问题。简化设计。 | 如果测试难写，简化接口。 |

## 关键原则

1. **生产代码 → 测试存在且先失败** = TDD
2. **否则** = 不是 TDD
3. **没有例外**（除非有合作伙伴的许可）

## 记住

- 测试通过的代码 ≠ 工作正常的代码
- 测试失败的代码 = 有问题的代码
- 先写测试的代码 = 你知道测试在测试什么

**TDD 不是教条，是务实。**