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

[GaliC2077]

公司想定了新的开发规则（为了收归测试人手，减少测试人力的投入，降本增效），推行单元测试（根据不同项目等级，覆盖率到 50-70%）

但是目前我们使用了 go 全局变量的框架，没有使用依赖注入，没有使用接口和抽象，导致非常难写单测

做了一下同事间的调研，大部分同事都不愿意写单测，理由大概是

• 没有时间，开发任务重
• 有时间连数据库自测都测完了

领导让我看一下这个事情怎么做，我尝试了一下，得出了三种方案。

1. 使用 sqlmock/连接内灰数据库来适配当前框架，可以做到没有外部调用系统的服务 mock 测试，但是遇到要调用外部服务的情况，无法 mock ，只能临时注释掉（因为没有使用依赖注入）。但是连接数据库不能算 mock ，用 sqlmock 要写的测试代码又太多，反对者比较多

2. 改造当前框架，拆分抽象层和实现层，使用依赖注入。这样单测想怎么写就怎么写就好了，但是增加大家平时要写更多代码，也有不少反对者

3. 听从同事建议，反馈领导，不推行单测，自行自测。（全靠自觉性，感觉领导层都不会同意

对此大家有什么比较好的建议吗？

另外最近在学英语，有什么英语读物推荐也可以分享一下（摸鱼/晨间日常）

发现很多人都在 AI 自动生成。但是我想说明一下，因为我们公司用的 Go 自研框架没有使用抽象，全是全局变量。
没有使用抽象，AI 也不可能生成出 UT ，没有办法 mock ，可能数据库还能用 sqlmock 的库 mock 一下，但是遇到要调用外部服务的还是无法 mock 。

我想说我们公司的人不是原始人，不会说因为不会用 AI ，所以上来问大家这种问题的。

[GaliC2077]

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

[KingHL]

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

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

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

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

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

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

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

[GaliC2077]

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

[GaliC2077]

@KingHL

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

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

[baby0w0]

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

[KingHL]

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

[Leon777]

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

[noyidoit]

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

[casillasyi]

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

[GaliC2077]

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

[air1314]

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

[RealYourDad]

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

[RealYourDad]

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

[supuwoerc]

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

[supuwoerc]

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

[doudou1523102]

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

[theniupa]

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

[chawuchiren]

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

[bzw875]

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

[winRain]

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

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

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

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

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

然后是怎么去做这回事：

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

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

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

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

[sagaxu]

我觉得还有第 4 种方案，抽调资源写 API 测试脚本，要求覆盖 50%以上的新增 API ，老 API 有变更时增加对应测试脚本。虽不如 UT 细致，但也能起到一定作用，而且这比写 UT 省事多了，也不会侵入框架和业务代码。我自己接的活，一般不写 UT ，但一定会写点 API 测试脚本，不仅方便自测，线上有问题时也能辅助诊断。

[ChangQin]

OP 最近有什么在读的英语读物分享吗

[fashionash]

明显就是考核过程指标呀，没有单测还有别的考核项，比如千行代码 bug 率、代码当量等等；如果你只是执行层的话就做数据统计，到个人、部门维度的排名；倒数的人总会自己想办法解决的

[FrankAdler]

我用 gomonkey ，基本上我写单元测试的部分覆盖率都是 100%，另外 orm 强烈推荐 entgo ，完美整合单元测试，原理是通过 sqlite 内存引擎来构造临时库

[yibin001]

@baby0w0 会变，单元测试对应调整

[crackidz]

降本增效当然是引入 AI 然后开人了

[Chase2E]

最起码要 integration test ，这样不管你内部怎么实现的，至少能覆盖上。然后再新的代码上推 unit test

[bao3]

你要么，不要理会同事的反馈，直接给老板提供方案，由老板来做决定。因为没有哪个人会同意给自己免费加工作量，包括你在内，所以你干脆忽略掉同事的反馈。

要么就告诉老板，现有资源做单测不现实。加人加钱加时间。 中国人还是太善于做牛马了，仍然想自己榨干自己。

[v1]

当领导开始推行单测同时砍测试同学的时候，基本上准备要卸磨杀驴了。

[xqk111]

工资不变，加大工作量，哈哈，谁干谁傻逼

[zw1one]

工作要给老板产生价值，情绪价值也是一种价值。

[shellic]

加工期，不加工期还让人写单测那肯定没人愿意啊，这不是增加工作量吗

[ZeroDu]

框架中间件这种不经常变动的可以。大部分公司的业务代码不适合写单元测试，经常迭代，在加上各个产品你改改我改改根本没法玩，更不要说任务重哪来的时间写

[SethShi]

不建议使用 sqlmock, 写太多了, 如果是 mysql, 可以使用 go-mysql 启动一个服务器, fakerredis, 等等,找对应的实现, 如果没有 , 就用 docker 启动容器. 参考这个:
https://www.shiguopeng.cn/posts/2024082617/

[guanhui07]

新项目可以搞,老项目怎么搞 ,单测覆盖率...领导有说排期 工期 加时间吗 得加钱加时间啊,一大堆领导瞎指挥 ,有本事自己上着带着我写 demo 能覆盖的,老项目逻辑覆盖不到的 你让我打哪就哪 , 只会怂恿 怂逼领导太多了

[qiaobeier]

@Biggoldfish #6 何不食肉糜

[Torpedo]

@peteretep #2 类似不就是招一个 sre 省成本。但是很多还是没有 sre 让大家自运维

[needhourger]

单元测试不能取代测试，别为了单元测试而单元测试。
只能说终究不过是老板想省钱了，省钱的同时还想了个冠冕堂皇的理由增加工作量，😆

[guguji5]

@15855pm 牛逼 [成本、效率、质量不可能三角] 学到了

[hellopz]

@peteretep 复杂业务还是得依靠测试用例，我们团队十几个人，跑一轮测试用例都几个小时了，每个大版本上百个小功能，纯人测肯定不行

[hellopz]

@zuosiruan 我们降本增效研发剩下一半，测试全裁了，研发自己解决测试

[Bluecoda]

国内就是这样，大部分都是鄙视测试的人，这些人大多都是落伍并且即将被淘汰的群体

测试不能消灭 bug ，但是可以防止代码被改坏。其价值不言而喻，在开发新功能并且动到老代码的时候，改坏马上就能知道，这里可以节省多少时间成本？

我几乎可以简单粗暴认为不屑写 test 的人=水平很烂，test 都不写，还能写什么东西？尤其 AI 时代，让其帮写测试不要太简单。以前写 rails 团队硬性要求必须要有基本 test ，也不要不过度 test 。现在写 python ，我一样要求团队写 test ，没有借口，不写就滚。

可能这么说有人不服，但是 AI 驱动开发的时代，写测试，让 AI agent 自己运行并且修改逻辑代码，这本身就是一个 best practice ，不用？等着被新人新技术淘汰呗

[ShawnLeex]

就我的关注点在楼主想要英语读物推荐吗哈哈，话说楼主找到了吗，同找

[irrigate2554]

想要代替测试人员的话单元测试没用，得写集成测试和 UI 测试

[lthon]

@winRain 平均一天 100 个的话，一年按 250 天算，也要 100 年

[LazyYum]

单测想要落实，必须融入到需求迭代的工作流程里，如果之前是快糙猛的流程，那不但不会减少时间，还会增加开发时间。

[Rorysky]

你说的 依赖注入 和 单元测试没什么必然关系呀

依赖注入 只是 模块解耦 的一种方式

[icyalala]

✅单测可以提升代码质量
❌单测可以降低人力成本

[dingyaguang117]

长期主义的话，还是要改造框架。接口的一个重要应用就是单侧

[dingyaguang117]

可测试性也是评价代码优劣的一个标准，虽然要改造很多，但是如果是长期维护的项目是值得投入的。 最最重要的是，领导一定要意识到改造是要投入人力的。我想目前大家抵触的原因是: 原有的业务需求不变，额外增加单侧工作。 所以这个是最重要的矛盾

[wxiao333]

国内的互联网公司，比如字节阿里，确实很多项目没有单元测试的

[kkeep]

太简单了。真不懂为什么你们觉得难

[wangxinyu]

主要还是接口测试，业务逻辑代码不需要测试，所有开发多提供接口才是重要的