不写，有问题用户会反馈的[= =]

@aw2350 很多种方法
1. stub 用自己的类代替
2. 如果写了 dao 层, 自己另外实现一个 dao 去返回
3. 没有 dao 层, 直接连接数据库操作对象, 可以 mock 数据库操作对象
4. 最后的办法可以启动一个数据库实例

楼上都是神仙吗, 90% 的单测, 话说你们的业务都很简单?

写，时间紧的话就先延后，找时间补上。

@seth19960929 同感，业务复杂的项目能做到百分之六七十的覆盖率就费了老劲了，太多的 stub 、mock 用例不仅写起来复杂而且测试的意义也大打折扣，很多时候就是为了完成 KPI

会的，后续业务有改动或者优化，或者有啥 bug 还是单测方便的

尽量覆盖主流程的简单情况，涉及外部系统就很难搞了

无副作用的核心方法必须单测。涉及数据库等外部操作的就等集成测试再说。单测覆盖率低的原因大概率是抽象不好，外部操作在核心业务逻辑中侵入太深

我们硬性要求 单测覆盖率增量 80% 低于则无法 MR
写业务代码和写单测时间 3:7

会给业务写集成测试，但单测基本没机会写。不写单测的原因有两个，一是我们的业务很少拆分成可测试的独立单元；二是我不想 mock 任何跟 io 相关的东西

😂测试代码要好写 业务代码得先写好