1. TDD基础概念：什么是测试驱动开发、TDD的红-绿-重构循环、TDD的优势与挑战
好，咱们直接进入正题。
测试驱动开发，英文叫 Test-Driven Development，简称 TDD。这名字听起来挺唬人，说白了就是——先写测试，再写代码。
你可能会问：「这不反了吗？正常人不都是先写功能再测试吗？」
嗯，我刚开始接触 TDD 时也是这个反应。当时我在做一个支付模块，自认为逻辑很清晰，吭哧吭哧写了两天代码，结果一跑全是 bug。修了一个，又冒出来两个。那种感觉，就像在打地鼠。
后来我试着换了个思路：先写测试，再写代码。效果出奇的好。今天我就把这里面的门道跟你聊聊。
什么是测试驱动开发
TDD 的核心思想其实就一句话：用测试来驱动你的代码设计。
传统开发流程是：需求分析 → 设计 → 编码 → 测试 → 修复。
TDD 的流程是：先写一个会失败的测试 → 写刚好能让测试通过的代码 → 重构优化。
你想想看，这两种方式最大的区别在哪？
传统方式里，测试是最后一步，是「验证」。TDD 里，测试是第一步，是「设计」。
我个人习惯把 TDD 理解为「用测试来倒逼设计」。因为你必须先想清楚「我要什么结果」，才能写出测试。这个思考过程本身，就是在做设计。
核心要点：
- TDD 不是测试方法，是设计方法
- 测试先行，代码后写
- 测试即文档，测试即规范
TDD 的红-绿-重构循环
TDD 的整个流程，可以拆成三个步骤。我习惯叫它「红-绿-重构」循环。
第一步：红（Red）—— 写一个失败的测试
你先写一个测试用例。这个测试用例描述了你想要的功能。
比如，你要写一个加法函数：
// 测试用例
test('1 + 2 应该等于 3', () {
expect(add(1, 2), equals(3));
});这时候 add 函数还不存在。运行测试，肯定失败。控制台会报红。
嗯，这里要注意：失败是正常的，甚至是预期的。红色代表你的测试是有效的，它确实能检测到问题。
我的经验：写测试时，先确保它真的会失败。我曾经写过一次测试，怎么跑都是绿色，后来发现测试本身写错了，根本没覆盖到真实逻辑。所以「先看到红色」是一个重要的验证步骤。
第二步：绿（Green）—— 让测试通过
现在，你写最少的代码，让测试通过。
int add(int a, int b) {
return a + b;
}运行测试，绿色。搞定。
这一步的关键词是「最少」。不要想太多，不要提前优化，不要写多余的逻辑。只要测试通过，就停。
你可能会觉得：「就这？这也太简单了吧？」
对，就是要简单。TDD 鼓励你小步快跑，每一步都稳扎稳打。
第三步：重构（Refactor）—— 优化代码
测试通过了，代码能跑了。但代码写得怎么样？有没有重复？有没有坏味道？
这时候，你可以放心大胆地重构。因为你有测试兜底。
// 重构前
int add(int a, int b) {
return a + b;
}
// 重构后（假设需要支持更多操作）
int add(int a, int b) => a + b;重构完，再跑一遍测试。绿色，说明重构没破坏功能。
红-绿-重构循环总结：
- 红：写一个会失败的测试
- 绿：写最少代码让测试通过
- 重构：优化代码，保持测试绿色
循环往复，直到功能完成。
TDD 的优势
我在多个项目里实践过 TDD，说说我感受到的几个实实在在的好处。
| 优势 | 说明 |
|---|---|
| 代码质量高 | 测试覆盖了大部分逻辑，bug 少很多 |
| 重构有底气 | 有测试兜底，改代码不怕改坏 |
| 设计更清晰 | 先写测试逼你思考接口设计 |
| 文档即代码 | 测试用例就是最好的使用文档 |
| 回归测试快 | 改完代码一键跑测试，秒级反馈 |
我记得有一次，一个老项目需要重构核心模块。如果没有测试，我根本不敢动。但那个项目有 90% 的测试覆盖率，我改完代码，跑一遍测试，绿了，直接上线。那种安全感，是没做过 TDD 的人体会不到的。
TDD 的挑战
当然，TDD 不是银弹。它也有自己的问题。
- 学习曲线陡：刚开始写测试时，你会觉得「写测试比写代码还慢」。这是正常的。坚持一段时间，速度会提上来。
- 不适合所有场景：UI 测试、集成测试用 TDD 比较困难。我一般只在业务逻辑层和数据层用 TDD。
- 维护成本：测试代码也是代码，也需要维护。如果需求频繁变更，测试也得跟着改。
- 团队共识：如果团队里只有你一个人写测试，很难坚持。TDD 需要团队文化支撑。
避坑指南：我曾经在一个项目里强行对所有 UI 组件做 TDD，结果测试写了一堆，每次 UI 改版测试全废。后来我学乖了：UI 层用快照测试，逻辑层用 TDD。各取所长，别死磕。
什么时候该用 TDD？
我个人建议，以下场景特别适合 TDD：
- 核心业务逻辑（比如支付、计算、校验）
- 需要长期维护的项目
- 多人协作的代码库
- 重构频繁的模块
以下场景可以适当放宽：
- 原型验证阶段
- 一次性脚本
- UI 布局和动画
说白了，TDD 是一种投资。前期多花时间写测试，后期省下大量修 bug 的时间。你想想看，是愿意现在花 10 分钟写测试，还是愿意以后花 2 小时排查一个隐蔽的 bug？
好了，这一章就聊到这。下一章我们会动手写第一个 TDD 示例，到时候你就能真正感受到「红-绿-重构」的节奏了。