单元测试落地避坑手记

上周帮杭州一个做电商SaaS的小团队救火。

他们刚上线的大促活动，三天亏了十七万。

原因说出来都可笑——优惠券满减的边界逻辑改了三版，没人写单元测试，最后一版把“满200减30”的阈值写成了“满199减30”，被羊毛党蹲点刷了两万多单。

我蹲在他们会议室翻代码的时候，CTO挠着头说，之前也想过写单元测试，觉得太费时间，先把功能赶上线再说。

太疼了。

真的。

凑数的测试根本不算测试

我见过太多团队把单元测试当应付领导的KPI。

打开测试文件一看，全是测getter、setter的，连那种直接返回常量的函数都要写个三行用例，跑一遍全绿，覆盖率直接干到90%以上，PPT上一放，好看得很。

真遇到核心逻辑改动，该漏的bug还是漏。

90%的覆盖率指标，有一半是凑出来的。

这种测试除了占磁盘空间，一点用没有。

之前在大厂待过的时候，有个组为了冲季度的覆盖率指标，专门花了一周时间写了一堆没用的测试，结果那周核心的支付逻辑改出了bug，线上停了俩小时，赔了不少钱。

没人去翻那些凑数的测试到底测了啥。

真正有用的单元测试，测的是你代码里最容易出错的部分。

不是那些一眼就能看到结果的简单函数。

哪些代码必须写单元测试

别上来就说要全量覆盖，小团队真扛不住。

你先把这几类代码的测试写了，性价比最高。

第一类，就是涉及钱的逻辑。

不管是优惠券计算、库存扣减、账单结算，还是支付回调的金额校验，只要跟钱沾边的，别偷懒。

就拿满减逻辑来说，你得测99.99的时候减不减，100整的时候减不减，199.99的时候是减30还是减60，要是叠加优惠券的话，抵扣顺序变了之后结果对不对。

这些边界值你写测试的时候列一遍，改代码的时候跑一遍，十秒钟的事，总比你上线后凌晨三点爬起来改bug强。

第二类，是涉及权限校验的逻辑。

比如普通用户能不能看到管理员的后台数据，能不能越权改别人的订单，这些逻辑写的时候觉得很简单，改个字段名就容易把判断条件搞反，一个测试用例就能兜住的事，别等到数据泄露了才后悔。

第三类，是那种写一次改半年的公共工具函数。

比如时间格式化、字符串处理、加密解密的逻辑，这种函数全项目都在调用，你改个参数，不写测试的话，根本不知道哪个业务会被你搞崩。

很多人说，写单元测试会拖慢开发速度。

真不是。

你算算账，写一个核心逻辑的测试用例，最多花十分钟。

要是这个逻辑上线出了问题，你排查、回滚、给用户赔礼道歉，花的时间是这十倍都不止。

写单元测试别搞太复杂

我最烦那种一上来就跟你讲TDD，讲什么“测试先行”，讲什么要把所有分支都覆盖到的“专家”。

小团队哪有那个精力？

你就记住，写测试的时候，别搞什么依赖注入的复杂框架，别为了测一个函数，搭一整套测试环境。

一个函数，你输入什么参数，预期输出什么结果，写三到五个最核心的用例就行。

比如那个满减的函数，你就写三个用例：

第一个输入99，预期不满足满减条件；

第二个输入100，预期减30；

第三个输入200，预期减60。

就够了。

别去测什么满10000的时候减多少，那种场景一年都遇不到一次，写了也是白写。

说实话，我现在带团队写测试，从来不会给大家定覆盖率指标。

我就问一句，你写的那个涉及钱的函数，有没有测边界？

有没有测你上次出bug的那个场景？

只要这两个做到了，就算你覆盖率只有30%，也比那些凑数凑到90%的强。

上周那个创业团队的CTO给我发消息，说他们现在把所有涉及优惠券、库存的逻辑都补了单元测试，上次改满减规则，跑了一遍测试，直接发现了两个边界问题，没上线就改了。

省下来的钱，够给团队发两次下午茶了。

对吧？

本来就没那么复杂。

别把单元测试当什么高大上的工程学理论。

它就是你写代码的时候，给自己留的个安全垫而已。