很多项目单元测试，只是用来应付评审的摆设
几乎所有团队都会要求写单元测试。
不少项目仓库单测覆盖率看着很漂亮，CI流水线全部绿色通过。
但是线上出bug，对应的模块单元测试却全部跑通。
很多单测只是摆设，只完成了“有代码”这个形式，没有真正起到防护bug的作用。
❌常见摆设式单元测试，看看你们项目中招几条
1. 只测正常快乐路径，完全不覆盖异常、边界场景
只传入理想参数跑一遍主流程，空值、异常、错误入参全部不写用例。
正常流程永远不会出错，真正容易崩的边界场景完全没有防护。
​
2. AI批量生成假单测（现在最普遍）
Copilot直接一键生成单元测试，简单调用一遍方法，断言返回对象不为null。
不去校验返回的数据内容，只要代码不抛异常就算通过。
哪怕逻辑改崩了，单元测试依旧绿灯放行。
​
3. 大量mock一切，把业务逻辑全部mock掉
把依赖的接口、数据库全部mock写死返回值。
业务内部逻辑被完全隔离，测试测的只是mock数据，根本测不到真实业务。
业务代码改了，mock数据没更新，用例依旧可以愉快通过。
​
4. 为了覆盖率硬凑代码
为了拉高覆盖率指标，无脑堆用例，重复场景反复测。
覆盖率数字很好看，但没有真正防护风险，属于纯完成指标。
​
5. 单测长期不维护，业务迭代代码更新，测试用例不更新
业务逻辑改了，单元测试随便改改就强行跑过。
时间久了，单测逻辑和真实业务已经脱节，变成过时的古董代码。
​
6. 测试只测工具类，核心业务逻辑几乎没有单测
简单工具函数写满单测，复杂的核心业务流程、数据库逻辑能省就省。
真正容易出线上故障的地方毫无保护。
✅真正有用的单元测试关注点
1. 重点测分支、边界、异常场景，而不是只跑通主流程。
空输入、非法参数、失败返回、并发分支，才是bug高发地。
​
2. 断言要有实质内容，不要仅仅断言不为null。校验返回结果、状态、异常信息。
​
3. mock要适度：外部第三方依赖mock，自身业务逻辑不要mock。
​
4. 业务改动，同步更新单元测试；需求变更，同步审视旧用例是否失效。
​
5. 不要迷信覆盖率数字。覆盖率100%不代表质量高；覆盖率低也不代表完全不行。
覆盖率只是参考指标，不是最终目标。
单元测试 后端开发 程序员 软件测试 AI编程 Copilot 代码质量 技术评审 开发感悟 软件工程

你们项目单元测试是真正起防护作用，还是属于摆设凑覆盖率？