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

2025 年 8 月 21 日
 GaliC2077

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

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

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

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

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

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

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

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

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

16820 次点击
所在节点    职场话题
153 条回复
darksword21
2025 年 8 月 21 日
首先不论是什么方法这个肯定是需要一定是时间改造项目,领导接受不了那就放弃

测试的话数据库可以不用 mock ,直接跑个测试用的每个 unit test 自己准备表和数据,跑完删表

和外部的调用就没办法了,只能改成依赖注入然后 mock
wtml
2025 年 8 月 21 日
你觉得在一样的工作时间内,能在保证代码质量和规范的前提下让开发写足够数量和质量的单元测试吗?
Martens
2025 年 8 月 21 日
go 的话使用 Monkey Patching 很简单做单元测试啊,直接把对应的函数打桩就好了,很久之前一个项目也是用全局变量面向过程一把梭
op351
2025 年 8 月 21 日
@GallifreyCAR 如果测试并不对代码进行测试,只是进行黑盒测试 我觉得单元测试并不能替代
原因:
1.单元测试只是对代码分支的覆盖性测试,只对最小单元的代码逻辑负责,不对实际功能负责。
2.我以前经历过的项目中,单元测试会被领导层以覆盖率为唯一指标进行追踪,导致开发人员编写大量的测试用例来覆盖所有分支,对正常开发进度严重干扰。
3.单元测试的高覆盖率不等于软件整体功能的高可用性,这也是我之前那个项目中出现的问题,单元测试覆盖率很好看,但是功能测试中仍然出现大量 bug 。

所以单元测试和功能测试不是替代关系,功能测试这种点点点的测试是必须的,要优化也是把功能测试的实际测试部分 RPA (自动)化,减少部分人力投入。
至于测试用例部分,未来可以考虑通过 AI 自动生成,但现阶段我觉得可行性需要再研究。
但测试自动化这块其实应用上已经相对成熟了,可以考虑做导入。
pandaPapa
2025 年 8 月 21 日
我刚才工作的时候, 必须要写单元测试. 后来前后端分离 就没人写了
holdonhope
2025 年 8 月 21 日
根本问题是要加排期
irisdev
2025 年 8 月 21 日
推单测没问题,想用单测完全替代测试有点难吧
midsolo
2025 年 8 月 21 日
单元测试只有国内互联网公司做的好一点,其他公司很难执行下去。

在互联网公司,项目的特点是时间紧,任务重,项目先上,等后面不忙了,再补单元测试跟文档。
就这样,一直都是紧急需求,已经有好几年的单元测试跟文档没补了。
jimrok
2025 年 8 月 21 日
你们的什么业务需要单元测试?不是核心业务搞单元测试成本你们盖的住不?就算都是 AI 写代码,后续还要有专人维护单元测试,需求稍微变动一下,单元测试就要重新更新。能支付这种成本的一般都是金融行业或者核心产品,代码修改如果没有单元测试验证,很难直接上生产。因为金融行业一旦出现 bug ,就是金钱的损失,不敢没有单元测试。
queue
2025 年 8 月 21 日
啥?你们想不增加研发人力或者成本的情况下,想通过单测降低测试成本?
想屁吃呢
300
2025 年 8 月 21 日
我们的单元测试就是掩耳盗铃,只能说是在提交测试的时候代码能通过,后面就没人跑了
jimrok
2025 年 8 月 21 日
@peteretep 也不是这样,一些复杂系统,单元测试比人靠谱多了,例如报税的系统,单元测试测的又快又准,你让一个人测,上百个功能点,不同的场景,让人去做,非常不靠谱。但要达到这样的效果,一个好的架构师是很必要的,首先要能高效的执行单元测试,整个代码的设计就必须满足可测的设计。模块的分离是不是够清晰,外部依赖的设计是不是容易构建,这些都影响单元测试的可实现。
huaweii
2025 年 8 月 21 日
首先搞清楚一件最基本的事情:单测全覆盖全通过,也不代表用户测试能通过
fredweili
2025 年 8 月 21 日
领导规定一个测试覆盖率,不愿做的,分不到钱啊,就这么简单
测试和文档 AI 能帮助的太多了,基本就是改改的事
alading11
2025 年 8 月 21 日
@bloomy8 #46 同意,在原来排期下加时间就完事了,这帮人老想着时间不变活你得多干,自己没当过大头兵吗?
jimrok
2025 年 8 月 21 日
你要实现单元测试,先把系统改造成单元测试友好的系统,一个手电筒的系统,灯泡可以单独测试,控制开关可以单独验证信号输出,电池可以单独测试电量输出的稳定性。但很多系统就是一座屎山,为了测一个功能,至少要拉起七八个模块,还不知道怎么能让每个模块正确初始化,每个场景都很难模拟,写单元测试的人就会直接崩溃掉。
gefranks
2025 年 8 月 21 日
前几年吃到 COVID-19 红利的公司, 2020 年中的时候开始运动式的搞单元测试轰轰烈烈的, 也是上面那个要求.
几年后我因为某件事情问一个开发经理, 你们的单元测试呢, 不是有单元测试么? 那位直接说, 那是假的, 不作数的.
不要只看一开始创建 UT 的成本投入, 后期维护的成本可大着呢。
ipwx
2025 年 8 月 21 日
@snowlyg http 相对容易,gorm 单测才是巨坑。我用 gorm + postgresql ,能改 table_prefix ,不能改 index 的(因为写在注解里面)。毕竟众所周之,pg 的 index 名称是库级别唯一,而不是 table 级别唯一,就很搞。
XueXianqi
2025 年 8 月 21 日
开猿节流,降本增笑嘛
fkmc
2025 年 8 月 21 日
go 写单元测试真的太难了.. 这一点真的不如 java

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1153924

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX