公司要推行单元测试，但是执行太过于困难，大部分同事不支持怎么办？

@wxw752 应该是变成 mvc 那样了.....

我在团队内推行过单测的落地，我们团队现在单测已经常态化运行，可以和楼主聊一聊：

首先我对“使用了 go 全局变量的框架，没有使用依赖注入，没有使用接口和抽象，导致非常难写单测”这个不是很理解，现在业界成熟单测框架对各类对象的 mock 功能已经非常成熟了，你这个难写是指难以组织单测目录结构、还是难以卸除可用的单测例子。

对于数据库，推荐使用 Sqlite 创建一个本地数据库，在单测环境初始化的时候创建表并插入数据，拒绝引入任何依赖，方便后续单测代码维护。

单测用例也有不同的写法，比如最细粒度的，针对函数/方法级别设计单测用例，这种的好处是单测用例好编写，坏处是单测用例基本没有组织逻辑，全是零散用例；也有把单测当成集成测试手段的，在功能入口处设计编写用例，每个用例都是有具体业务含义的，这种好处是单测用例易于设计，运行成功代表功能可用，但是需要进行大量的下游调用方 mock 和数据组织，维护复杂度高。

单测写完只是第一步，对单测用例的维护是一个非常重的工作，必须前期设计好单测运行流程、单测组织结构、单测用例编写规范，建议从某个独立工程开始试点，真正把单测的编写和维护流程跑通，拿到收益。

单测会反推开发者进行更合理的代码结构拆分，提高代码质量，建议从增量代码开始卡点，增量代码写单测负担小，易于推行，并且效果直观。

单测代码行覆盖率只是一个可用观测指标，都是 70%的行覆盖率，单测真正覆盖了多少业务场景，执行了多少分支流程差别很大，重要的还是用例设计，所以建议 CR 对用例进行 review 。

@NX2023 #81 我也不太接受，只有写这个 demo 的时候试验过，正式要搞太折磨了，不如直接改框架。

@KingHL

也有把单测当成集成测试手段的，在功能入口处设计编写用例，每个用例都是有具体业务含义的，这种好处是单测用例易于设计，运行成功代表功能可用，但是需要进行大量的下游调用方 mock 和数据组织，维护复杂度高

我们其实就是这种情况，业务要大量 mock 数据库返回，mock 缓存队列返回，mock 一些外部服务系统的返回，
要用上 各种库才能实现，类似 gomonkey, sqlmock 等等。所以我还是希望改造改造框架为依赖注入，拆分出抽象接口。但是我在同事间调研，大家不想写的心情居多，看了 v2 回答，我觉得可能向上反馈，不推行也是一种方案。

@momo2789 你的理解没问题的。钱给够就可以了

@GallifreyCAR 参考我的回复，建一个 sqliite 本地数据库，注入到你的 orm 的 client 上，即可实现数据库替换，单测时会走到真正的数据库操作代码，不需要做数据库返回值的 mock ，数据库读写逻辑本身就是一个需要单测覆盖的部分，不建议直接 mock 掉数据库。

写单测开发时间不说翻倍起码也增加百分之 50 吧，旧代码不重构根本写不了

你们这个项目恐怕不是“非常难写单测”而是写不了单测吧

微服务时代，单测就是给自己找麻烦。走自动化的 API 测试吧。

@KingHL #106 那样的话，其实我们公司提供了测试环境的数据库，只是不经常维护而已

单元测试是非常必要的，前期投入点时间，后期能省很多事，特别是项目越来越大，没有单元测试很难保证代码及提测质量
如果代码难写单元测试，那就是代码设计不好，该拆拆，这种是技术债，在保证业务的情况下慢慢排期改，不需要一下子就一步到位
新代码及项目必须强制要求单元测试，老项目可以不着急，有空加点，可以让 AI 帮助生成

想通过增加单元测试来减少测试人力投入并实现降本增效这个结局大概率是要失败的。
原因如下：
要维护测试脚本的有效性，需要占用大量开发的时间，实际上你是把测试的成本从测试人员转移到了开发人员身上。或许确实不需要有专门的测试了，但是开发需求的时间会大大延长，只有真正尝试过这种开发体验的人才能明白，自动化测试的要求比人力测试是更高的。加上开发人员的成本一般来说比测试要高，所以实际上想要达到降本增效的可能性不是很大。当然不可否认的是，大量且完善的自动化测试对保障代码质量很有帮助，但还是那句话，降不了成本。

@zaunist 我说这个话并不是说单测不重要，而是想说通过增加开发的工作量，然后开掉测试这种行为本身实现不了降本增效。

光是抽象接口&依赖注入基本上就是重构整个项目，我觉得如果是项目早期改造下还来得及，已经开始一段时间的项目就别搞了，大量的重构会让代码更乱

或者不用 mock 的思路，改用 fake 的思路？

听你领导的就完事了，至于你执不执行下去，看实际情况推进。

SDK 类，或偏固定接口框架 的工程 巨量的单元测试代码用例编写开发投入才有价值。

@peteretep 想多了，写单元测试领导想的是 0 成本，不额外计算时间

不写单测，花 6k 月薪找大学生做测试

我现在这家公司写了三百多万个 UT ，说点我的想法。

首先对于这个事在职场的考虑：

站在你的角度，领导来让你给方案，绝对不是想听到什么我觉得这个很难搞，弄不了，都觉得不想弄等等之类的话。让你给方案，说明领导对你的技术水平比较信任，你应该客观的分析优点，缺点，难处。

假如你是实在不想弄，也应该在难处上下功夫，让他知道这个东西不好弄，风险点等等之类的，想好如果实行不下去，怎么处理。

领导找你来是让你来解决问题的，不是听这个东西多难，不想做。

然后是怎么去做这回事：

我觉得你们应该先考虑用黑盒测试，去保证业务测试。业务测试最关键的是数据库数据的处理，不考虑 mock ，而是去考虑实现一个 UT 的 teardown ，手动管理 UT 事务。

之后，慢慢解耦，在 cotnroller 、service 、mapper 这三层之外多加一个 domain 层，做业务逻辑的计算。入参和结果都是 DTO 那种。

同时，也要考虑用 AI 加速，让领导上 copilot 。还要考虑未来 UT 如何处理，代码管理、review 等一系列问题。还有加入 UT 之后，工时变长等等。

这些问题都是你在方案里需要考虑的，需要领导提供资源支持的。好的领导和差的领导这个时候就能体现出来，又要马儿跑，又要马儿不吃草这种我建议你就直接考虑下一家。