上周去南京软件谷见个老同事，他们团队做本地生活商家后台的，刚被CTO下了死命令——三个月内单元测试覆盖率从28%拉到70%，不然季度绩效全扣。几个人熬了两个通宵硬凑了一堆空测试，覆盖率冲到41%，结果上线第三天，商家提现的金额计算逻辑崩了，亏了十几万。
真的冤。
他们凑的那些测试根本没碰核心逻辑，全是给getter setter写的断言，跑起来绿得发光，实际半毛钱防护作用没有。说穿了就是为了凑数字交差，把单元测试当成了应付考核的任务，完全忘了写测试的初衷是什么。
别把覆盖率数字当最终目标
很多人对单元测试的误解，从一开始就错了。
觉得只要数字够高，代码质量就一定好。真的不是。你花十分钟给一个纯传参的接口写三个测试，和你花两小时给金额计算逻辑写五个覆盖所有边界的测试，后者的价值是前者的几十倍。
我之前见过一个Java团队，整体覆盖率冲到了78%，看起来特别漂亮，结果统计了下，其中60%的测试都是给实体类、简单工具方法写的，真正涉及交易、权限、状态流转的核心模块，覆盖率还不到30%。这种数字看着好看，遇到异常场景根本顶不住。
说实话，真没必要为了凑数字写一堆没用的测试。你写的每个测试，最后都是团队要维护的资产，如果写的测试根本没有验证核心逻辑，那每次改代码的时候，还要花时间调整这些无意义的测试用例，反而成了开发的负担。
覆盖率数字从来不是目的，能拦住线上bug才是。如果你的测试跑全绿，但是遇到金额算错、权限越权、状态卡死的问题就直接失效，那哪怕覆盖率到100%，也只是自欺欺人。
优先补高风险模块的测试，别瞎忙活
很多团队刚推单元测试的时候，一上来就从最简单的CRUD模块开始补，觉得这些模块逻辑简单，写测试快，能快速把整体覆盖率拉上去。
错。
你给100个普通的商家列表查询接口写测试，带来的价值，可能还不如给一个提现金额计算的模块补全测试用例。毕竟前者就算出问题，最多就是列表加载慢一点，后者出问题，是直接要赔真金白银的。
正确的做法是先把最近3个月所有的线上bug工单拉出来，按影响范围、损失金额排个序，把那些出过资损、出过用户投诉的模块，列成最高优先级的补测对象。先把这些模块的核心逻辑覆盖率拉到80%以上，再去碰那些边缘的、出问题也没什么影响的模块。
别再用”整体覆盖率”当唯一的考核指标了。你可以把统计维度拆细，核心交易模块单独设80%的覆盖率阈值，普通业务模块设50%，边缘工具类模块甚至可以不设硬要求。这样大家不用把时间浪费在凑无意义的数字上，真的把测试写到刀刃上。
上次有个做社区团购的团队就是这么改的，之前为了凑整体70%的覆盖率，大家天天给地址校验、图片上传这种简单接口写测试，结果优惠券叠加计算的逻辑连个测试都没有，每个月都要出好几次算错金额的问题。改了规则之后，大家先把优惠券、拼团、退款这三个核心模块的测试补全，花了不到两周，这三个模块的覆盖率就到了85%，之后连续三个月都没出过相关的资损问题，省下来的救火时间，比写测试花的时间多好几倍。
几个能省一半时间的写测试小技巧
很多人觉得写单元测试太费时间，尤其是那些嵌套了三四层依赖的业务接口，写一个测试要mock半天数据库、第三方接口、缓存，花的时间比写业务代码还多。
其实只要稍微调整下代码结构，写测试的成本能降一大半。
把核心业务逻辑从控制器、服务层里拆成纯函数。什么是纯函数？就是传固定的参数，一定返回固定的结果，不依赖外部的数据库、缓存、第三方服务。比如你算满减金额、算运费、判断用户有没有权限，这些逻辑完全可以拆成独立的纯函数，写测试的时候根本不用mock任何外部依赖，直接传参数就能跑，写测试的速度至少能快3倍。
我之前遇到个开发，说他们的下单接口写了两千行，根本没法写测试。我让他花一下午把里面算满减、算优惠券、算运费的逻辑拆成三个独立的纯函数，他拆完之后，写这三个函数的测试只花了40分钟，覆盖率直接涨了18%，比他之前对着那坨两千行的代码盯三天效率高多了。
还有个偷懒的办法，就是把已经跑通的线上真实请求，存成测试样本。很多人写测试的时候总拍脑袋想边界值，其实你直接把线上真实用户的下单请求、提现请求的入参和正确的返回值存下来，直接拿来当测试用例，比你自己瞎想的用例靠谱多了，还能省下来好多造数据的时间。
哦对，还有个容易踩的坑，写测试的时候别只测正常场景。你不能只传正常的金额、正常的用户ID去测，还要测传负数、传超大值、传空值的异常场景。这些场景才是最容易出线上bug的地方。
其实推单元测试从来不是什么很难的事，别把它当成给开发加的负担，也别把覆盖率数字当成要完成的KPI。你只要记住，写的测试是帮你自己少熬夜救火，是帮团队少赔冤枉钱，很多事就顺了。
对了，今天下班前可以先做一件事：把团队最近出过bug的核心模块列个表，明天就从第一个模块开始补测试，别等下次出了资损再后悔。