https://github.com/bytedance/mockey/tree/main 我司要求覆盖率是 80% ，持久层可以商量忽略单元测试覆盖，业务层还是有必要的。

@GallifreyCAR #78 个人感觉 go-sqlmock 这种写法不太能接受，所以我没按照这种方式（

@baby0w0 覆盖率不是目的，它是客观指标！有这个覆盖率能保证下限。没有覆盖率的约束，程序员很容易在写测试时“顾头不顾尾”，导致关键路径没人测。

@yibin001 你们的业务不经常变化吗？ 如果变化了，那么单测的逻辑也要改，是可以接受的？

@GallifreyCAR #78 关键是直接起一个实例来读写很方便，用 go-sqlmock 的 ExpectExec 不如执行完 SELECT 一下看是否符合修改后的预期

单元测试做单独的排期, 覆盖率列入绩效考核, 而不是说开发周期加上单元测试

@momo2789 那我明确的告诉你，业务代码写的不好的人，他的单测也写的不好

你们老板这是花了一碗粉的钱，想吃两碗粉

@baby0w0 那我只能说你踩的坑不够多，或者这么说吧，你还没入行。

单元测试工作量确实很大，但能直接关联代码覆盖率。 如果一段代码不方便做单元测试，大概率不是好代码，以应付单元测试和覆盖测试的心态写代码，能迫使开发人员写出方便复用的代码段