---
name: execution-tdd
description: 测试驱动开发。严格的 RED-GREEN-REFACTOR 循环。铁律：没有失败测试就不写产品代码。
---

# 测试驱动开发(TDD)

## 铁律

```
没有失败测试就不写产品代码。
```

## 循环

### RED — 写一个失败的测试

1. 写一个描述期望行为的测试
2. 运行测试，确认它失败
3. 测试失败的原因必须是"功能还不存在"

### GREEN — 写最少的代码让测试通过

1. 写刚好够让测试通过的代码
2. 不多写。YAGNI。
3. 运行测试，确认全部通过

### REFACTOR — 清理代码

1. 在测试保护下重构
2. 消除重复
3. 改善命名
4. 运行测试，确认仍然全部通过

## 合理化防御表

| 你可能的想法 | 现实 |
|-------------|------|
| "这个改动太小不需要测试" | 小改动也会引入 bug。先写测试。 |
| "测试会花太长时间" | 不测试会花更长时间调试。 |
| "这个函数太简单了" | 简单函数也会有边界情况。 |
| "我先实现再补测试" | 事后测试无法驱动设计。先测试。 |
| "现有测试已经够了" | 新行为需要新测试。 |
| "这个 edge case 不太可能发生" | 不可能发生的事总会发生。 |
| "重构可以等一等" | 技术债会复利增长。 |
| "文档可以后面再写" | 后面 = 永远不。现在写。 |
| "性能优化不急" | 等用户抱怨就来不及了。 |
| "这个 TODO 我记住了" | 你会忘的。写下来。 |
| "其他模块更重要" | 每个模块都是最重要的。 |

## 红旗

这些想法意味着 STOP — 你正在合理化：

| 想法 | 现实 |
|------|------|
| "我先写实现再补测试" | STOP。先写测试。 |
| "这个不需要测试" | 如果它需要工作，它需要测试。 |
| "测试太多了" | 代码太多了还差不多。 |
| "这个 edge case 不重要" | 不重要的 edge case 经常是最重要的 bug。 |
| "测试会让我变慢" | 没有测试会让你更慢。 |

## 压力测试

在声称完成前，问自己：

1. 如果输入是空的怎么办？
2. 如果输入是 null/undefined 怎么办？
3. 如果并发 1000 个请求怎么办？
4. 如果网络断了怎么办？
5. 如果磁盘满了怎么办？
6. 如果数据库连接超时怎么办？
7. 如果用户输入包含特殊字符怎么办？
8. 如果配置缺失怎么办？