单元测试值得写吗？从原理到实践一次讲清

程序员群体里流传着一种真实的分歧：一派认为单元测试是“浪费时间”，理由是“业务催得紧，写测试的时间够我写两个功能了”；另一派视测试为职业护城河，重构时敢大刀阔斧、上线后睡得安稳。谁对谁错？答案是：单元测试不是“该不该写”的道德问题，而是“成本与收益如何计算”的工程问题。理解了它的运作原理，你自然会知道什么时候写、怎么写、写到什么程度。

单元测试到底在保护什么？

单元测试是对代码中最小功能单元（通常是一个函数或方法）的自动化验证。它的核心价值有三层。第一层是回归保护：没有测试的代码，改一行可能悄悄破坏另一个功能，而回归bug往往在几周后才在线上爆发；有了测试，每次改动跑一遍全量用例，破坏当场现形。第二层是设计反馈：单元测试强迫你把代码拆成可独立调用的小单元，如果一个函数“没法测”，通常是它在暗示你——依赖太多、职责太杂、耦合太深，这种“可测试性”信号是最早也最便宜的设计评审。第三层是活文档：一组写得好的测试，就是代码行为的可执行说明书，新人接手时看测试比看注释更可靠。理解了这三点你就会明白：写测试的时间不是成本，而是为“未来的每一次改动”买的保险。

写好单元测试的四个关键

第一，遵循AAA结构： Arrange（准备输入与依赖）、Act（调用被测函数）、Assert（断言结果），三段清晰分离，测试即文档。第二，每个用例只验证一个行为，用“方法名加场景加预期”命名，比如“calculatePrice_含会员折扣_返回折后价”，失败时一眼定位问题。第三，保证隔离与确定性：不依赖真实数据库、网络和系统时钟，用桩（stub）和模拟（mock）替换外部依赖，让测试在任何机器、任何时间跑出同样结果。第四，关注行为而非实现细节：断言“返回了正确的折扣价”，而不是断言“内部调用了某个私有函数”，否则实现一改测试就碎，测试反而成为重构的阻力。

案例：一次有惊无险的重构

一位后端同事接手了一个订单模块，代码风格混乱但功能正常，他决定重构。同事劝他“能跑就别动”，但他先花了两个下午把核心计算逻辑的关键路径补了三十多个单元测试，覆盖了折扣、税费、运费、异常分支各种组合。重构开始后，他几乎每改一个函数就跑一遍测试，先后抓出了三处因逻辑顺序调整引入的隐性错误——如果没有测试兜底，这些错误会在重构合并后悄然上线。重构完成后，测试全绿，他长舒一口气：这正是单元测试最经典的用法——它是重构的安全网，让你敢于改进代码，而不是让代码越来越烂直到无人敢碰。

常见误区

• 追求覆盖率数字：100%覆盖率的烂测试（只断言“不报错”）比没有测试更糟，有价值的是覆盖关键行为与边界的测试。
• 测试内部实现：与私有逻辑强耦合的测试，会在每次重构时破碎，测试应当锁定“对外行为契约”。
• 什么都mock：把被测函数自己的逻辑也mock掉，测试就失去了意义，mock只应用于外部依赖。
• 把集成测试、端到端测试当单元测试：跑得慢、依赖环境、不稳定，混在一起会让测试套件变成负担，不同类型要分层存放。

行动建议

• 从“高价值低难度”入手：给工具函数、价格计算、状态流转这类纯逻辑先补测试，见效最快。
• 修bug时先写一个能复现该bug的失败测试，再修复代码直到测试通过，防止同类问题回归。
• 把测试纳入提交门禁：每次提交自动跑相关用例，让“跑测试”成为肌肉记忆。
• 如果团队完全没有测试文化，先争取“核心模块必须有测试”的小范围约定，用一次重构或故障的实例说服团队。