写单元测试的时候，很多人习惯只走 happy path。
拿到入参合法的场景，跑一遍，断言结果正确，测试用例通过，就觉得这个接口已经覆盖完成。
可线上故障，几乎从来不出在正常流程里。
就拿参数校验来说，传空数组、超长字符串、边界极值，这些场景常常被直接跳过。开发心里默认这类请求不会进来，交给上层拦截就完事。一旦网关、前端校验出现漏洞，脏数据直接打进底层逻辑，程序直接异常。
还有异常分支的测试，try catch 里面的逻辑很少有人专门写用例覆盖。
异常抛出之后，事务有没有回滚？消息有没有重复投递？返回码是否符合预期？这些点不跑一遍，你根本不知道异常发生时系统会做出什么反应。代码覆盖率看着很高，其实只是主干通路跑通，异常分支完全是黑盒。
还有一类容易忽略的点，并发下的单元测试。
普通单线程测试完全没问题，多线程同时操作同一个资源，就会出现状态错乱。单线程的单元测试无法复现这类问题，等到上线并发上来，问题才会暴露。
不少团队把单元测试当成任务，为了覆盖率指标而写。
写完跑绿，提交合并，就算完成任务。这样的测试，只能证明代码在理想条件下能跑，不能保证它能扛住真实环境的各种意外。
好的单元测试，重点不是验证 “正确输入得到正确结果”。
而是验证，当输入乱七八糟、程序抛出异常、资源抢占冲突的时候，系统依旧可控。
只测正常流程的测试用例，更像一份形式上的文档，没法帮我们提前拦截线上隐患。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/acd12009/article/details/167566192
