单元测试与TDD：从“写代码像开盲盒”到“稳如老狗”的蜕变

如果你曾经在深夜部署代码后，被一个电话叫醒：“线上挂了！”；或者你在重构一个函数时，像拆炸弹一样小心翼翼，生怕动一根线就炸了整个系统——那么，你可能需要一场与“单元测试”和“TDD”（测试驱动开发）的深度对话。

一、为什么我们需要单元测试？——别让你的代码“裸奔”

想象一下，你写了一栋房子，但没有做任何承重测试、防水测试，甚至没检查过地基。你敢住进去吗？很多开发者的代码就是这样——功能看似跑通了，但一遇到边界条件、并发请求、异常输入，就开始“漏雨”。

单元测试的价值在于：

• 提前发现低级错误：比如空指针、越界、逻辑分支遗漏。这些错误往往在集成测试或线上才会暴露，而单元测试可以在你写完代码的下一秒就抓住它们。
• 重构的“安全网”：没有测试的代码，重构就像在雷区散步。有测试覆盖，你可以大胆地改，跑一遍测试就知道有没有踩雷。
• 文档的“活标本”：好的单元测试本身就是一份可执行的文档。新同事接手时，看测试用例就能明白函数的预期行为。

二、TDD：先写测试再写代码，反直觉但真香

TDD（Test-Driven Development）的核心循环是：红 -> 绿 -> 重构。

1. 红：先写一个会失败的测试（因为功能还没实现）。
2. 绿：写最简代码让测试通过。
3. 重构：优化代码结构，同时确保测试依然通过。

听起来很反直觉？我第一次尝试时也觉得：“这不是浪费时间吗？我连代码都没写，怎么知道要测什么？”但实践后才发现，TDD最大的魔力在于：它逼你思考“输入输出”而非“实现细节”。

举个栗子：写一个计算器加法函数

传统做法：直接写 function add(a, b) { return a + b; }，然后手动测几个数，觉得没问题就提交了。

TDD做法：

1. 先写测试：expect(add(2, 3)).toBe(5); —— 测试失败（红）。
2. 写代码：function add(a, b) { return a + b; } —— 测试通过（绿）。
3. 重构：考虑边界情况，比如 add('1', 2) 应该报错吗？于是加测试：expect(() => add('1', 2)).toThrow() —— 又变红，继续循环。

你看，TDD让测试从“事后补”变成了“事先设计”。它强迫你定义好“什么是对的”，再动手实现。这就像盖房子前先画好蓝图，而不是边盖边改。

三、实战经验：如何写出“好”的单元测试？

1. 测试要“快”且“独立”

• 快：一个单元测试应该毫秒级完成。如果测试需要连数据库、调外部API，那就不是单元测试，而是集成测试。用Mock（模拟）替代外部依赖。
• 独立：每个测试用例之间不能有依赖。测试A不应该依赖测试B的执行结果。常见反例：测试A往数据库插了一条数据，测试B去读取。一旦顺序打乱，测试就挂了。

2. 覆盖边界，而非“开心路径”

很多人的测试只覆盖了“正常输入”的情况，比如：

• 输入正整数，返回正确结果。
• 输入合法邮箱，返回true。

但真正出Bug的往往是边界：

• 输入0、负数、极大值。
• 输入空字符串、null、undefined。
• 输入特殊字符（如SQL注入尝试）。

建议：写测试时，先列出所有可能的“坏输入”，然后确保每个坏输入都被测试覆盖。

3. 测试命名要像“故事标题”

不要写 test('test1') 或 it('should work')。好的测试命名应该让人一眼看出在测什么场景：

• test('当输入为空字符串时，函数应返回默认值')
• test('当用户未登录时，应抛出401错误')

这样，当测试失败时，你立刻知道哪个场景出了问题，而不用去读代码。

4. 避免测试“实现细节”

测试应该关注“行为”而不是“实现”。比如，你有一个排序函数，你测试的是排序结果是否正确，而不是测试它内部用了冒泡排序还是快速排序。一旦你换了算法，测试依然应该通过。

反例：测试某个私有方法是否被调用。这会让测试与代码实现高度耦合，重构时测试跟着全改。

四、常见误区与心态调整

误区1：测试覆盖率100%就万事大吉

错！覆盖率只代表代码行被执行过，不代表逻辑被验证了。比如：

1
2
3
4
5

if (a > 0) {
  return 'positive';
} else {
  return 'non-positive';
}

你写一个测试 expect(func(5)).toBe('positive')，覆盖率就达到了50%（if分支被覆盖）。但else分支根本没测。所以，覆盖率是手段，不是目标。目标是用测试验证所有逻辑分支。

误区2：TDD太慢了，不适合敏捷开发

初期确实会慢，因为你要花时间写测试。但随着项目变大，你会发现：

• 调试时间大幅减少（测试帮你定位问题）。
• 回归测试自动化，不用手动点来点去。
• 重构时更自信，速度反而提升。

我的经验：一个功能，如果不写测试，开发+联调+修Bug可能需要4小时。写测试可能前1小时在写测试，后3小时在写代码和调通，但后续几乎不用再花时间修Bug。长期看，TDD是“慢就是快”。

误区3：测试代码不需要维护

测试代码也是代码，同样需要重构、保持整洁。如果测试代码写得像意大利面，没人愿意改，最终测试会被废弃。记住：测试是项目的资产，不是负债。

五、工具推荐与入门建议

• 语言对应测试框架：
  • JavaScript/TypeScript：Jest（最流行，内置断言、Mock、覆盖率）
  • Python：pytest（简洁、插件丰富）
  • Java：JUnit 5 + Mockito
  • Go：testing 标准库（简单够用）
• 入门步骤：
  1. 从一个小模块开始，比如一个工具函数（日期格式化、字符串处理）。
  2. 尝试用TDD重写一个你之前写过的简单函数。
  3. 逐步扩展到业务逻辑，比如用户注册、订单计算。
  4. 坚持两周，你会发现自己写代码时下意识会想“这个情况测试能覆盖吗？”

结语

单元测试和TDD不是“银弹”，但它们是目前为止，我见过最靠谱的“防弹衣”。它们不能阻止你写Bug，但能让你写Bug时立刻知道，并且安全地修复它。

下次当你写完代码准备提交时，不妨问自己一句：“如果这个函数被改了，我敢不敢直接上线？”如果答案是否定的，那就去写测试吧。毕竟，谁不想做一个“稳如老狗”的开发者呢？