单元测试与TDD实践

2026-04-28

字数统计: 1.5k字 | 阅读时长≈ 5分

单元测试与TDD：从“验收焦虑”到“代码自信”的蜕变

还记得你第一次写单元测试时的感受吗？我猜多数人会回答：“麻烦”、“浪费时间”、“业务都忙不完，还写测试？” 这很正常。我们总觉得自己写的代码是完美的，直到某个深夜，一个看似无害的改动让整个系统崩溃，你瞪着屏幕，欲哭无泪。这时你才明白：没有测试的代码，是悬在头顶的达摩克利斯之剑。

今天，我们就来聊聊单元测试和TDD（测试驱动开发）。这不仅是技术实践，更是一种思维方式的转变。我会用亲身经历告诉你：如何从“验收焦虑”走向“代码自信”。

一、单元测试：不是“额外工作”，而是“安全网”

先纠正一个误区：单元测试不是测试人员的事，也不是项目做完后的“附加题”。它是一张安全网，让你在重构、添加功能时，敢大胆地修改代码。

什么是好的单元测试？

独立性：不依赖数据库、网络、文件系统。你测试的是逻辑，不是环境。
可重复：无论跑多少次，结果一致。
快速：毫秒级完成，否则没人愿意跑。
单一职责：一个测试只验证一个行为。

举个反例：我见过有人写测试时，先启动Spring容器，再连接测试数据库，最后调用API接口。这叫“集成测试”，不是单元测试。跑一次要30秒，谁受得了？

实战建议：如何开始？

从“核心逻辑”入手。比如一个计算折扣的函数、一个校验用户输入的规则、一个状态机转换。这些地方最容易出错，也最容易通过单元测试覆盖。

# 一个简单的折扣计算函数
def calculate_discount(price, user_level):
    if user_level == 'vip':
        return price * 0.8
    return price * 0.95

对应的测试：

def test_vip_discount():
    assert calculate_discount(100, 'vip') == 80

def test_normal_discount():
    assert calculate_discount(100, 'normal') == 95

简单吧？但正是这些“简单”的测试，能拦住80%的回归bug。

二、TDD：先写测试，再写代码？这不是“反人类”吗？

第一次接触TDD时，我的反应是：“代码都没写，我怎么知道测试什么？” 这感觉就像让你先设计一座桥的承重测试，再开始画图纸。听起来很荒谬，但实际体验后，我才发现它的魔力。

TDD的三步循环：红-绿-重构

红（Red）：先写一个会失败的测试。这个测试描述了“你想要的功能”。
绿（Green）：写最简代码让测试通过。不追求完美，只求通过。
重构（Refactor）：在测试的保护下，优化代码结构，消除重复。

一个真实的案例

假设你需要实现一个“用户注册”功能，要求用户名至少3个字符。

第一步：写测试（红）

1
2
3

def test_username_too_short():
    result = register_user('ab')  # 假设这个函数还不存在
    assert result == '用户名至少3个字符'

运行测试，必然失败——因为register_user还没写。

第二步：写最简代码（绿）

def register_user(username):
    if len(username) < 3:
        return '用户名至少3个字符'
    return '注册成功'

测试通过。

第三步：重构
现在代码很简陋。但没关系，你可以在测试的保护下，提取常量、添加日志、或者改成异常抛出。只要测试依然通过，你就知道改动没破坏功能。

为什么TDD值得尝试？

设计驱动：先写测试迫使你思考“这个函数应该怎么用”，而不是“怎么实现”。这往往能设计出更清晰的接口。
只写必要的代码：TDD让你避免“过度设计”。测试只要求通过，你自然只写刚好够用的代码。
心理安全：当你准备重构一个庞大的模块时，TDD生成的测试套件就是你的“降落伞”。

三、常见陷阱与实用经验

陷阱1：测试与实现耦合太紧

错误示范：

1
2
3

# 测试直接断言内部方法的调用次数
def test_send_email():
    email_service.send_email.assert_called_once()

如果后来你把send_email重构成了send_email_v2，测试就废了。

正确做法：测试行为，而非实现。只验证输入输出，不关心内部细节。

陷阱2：测试写得太“重”

我曾经见过一个项目，测试代码比业务代码还长3倍，因为每个测试都要mock 10个依赖。这通常是设计不良的信号——你的函数做了太多事。

解决：拆分成更小的函数，或者使用依赖注入，让测试更容易构造。

陷阱3：100%覆盖率崇拜

别追求100%覆盖率。那往往是浪费时间的数字游戏。优先覆盖核心逻辑、边界条件（如空值、负数、最大长度）、异常路径。

我的经验：80%的覆盖率，配合良好的测试质量，已经能覆盖95%的bug。

四、从“验收焦虑”到“代码自信”

写单元测试和TDD，最大的收获不是减少bug（虽然它确实能做到），而是心理上的转变。

以前：每次上线前，手心出汗，默默祈祷。
现在：一键运行测试，看到绿色通过，心里有底。
以前：不敢重构代码，因为不知道会破坏什么。
现在：大胆抽取函数、优化性能，因为测试在背后撑腰。

最后送你一句话：写测试不是“浪费时间”，而是“投资时间”。你今天花30分钟写的测试，可能在三个月后救你一命。

行动建议：从今天开始，尝试在一个小功能上实践TDD。哪怕只是一个计算器、一个日期格式化函数。感受“红-绿-重构”的节奏。相信我，一旦你尝到测试带来的安全感，就再也回不去了。

互动话题：你在写单元测试时，遇到过最奇葩的bug是什么？欢迎在评论区分享你的“测试血泪史”。

本文作者： 来的太快的龙卷风
本文链接： https://my-hexo-blog-4i4.pages.dev/2026/04/28/2026-04-28-单元测试与TDD实践-d2dcc87f/
版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！