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

2025 年 8 月 21 日
 GaliC2077

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

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

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

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

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

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

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

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

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

16820 次点击
所在节点    职场话题
153 条回复
dddd1919
2025 年 8 月 21 日
首先单测的目标是啥?如果就以覆盖度为目标,写的那种方法调用的单测或者丢给 AI 生成的单测代码基本对项目质量起不到什么大作用,要能自顶向下的模拟真实测试覆盖功能测试才真的有意义。

如果要搭建一套完善的测试,起手也相当麻烦,最好前期先把基础工作搞好比如测试框架选型和铺底数据构造以及 mock 工具以及规范单测原则等等等。另外也可以从一些点出发开始写单测,比如后续发现的开发 bug 必须要用单测做回归覆盖
v2hh
2025 年 8 月 21 日
我之前公司也是,要求单元测试覆盖率 80%,就这一句话就是标准。
qbmiller
2025 年 8 月 21 日
找个人写白盒测试,不走单元测试呢
arischow
2025 年 8 月 21 日
我日常开发的项目最差的测试覆盖都有 70%,还是跑了 15 年的项目
qbmiller
2025 年 8 月 21 日
@qbmiller 找关键功能、业务点,写一些白盒测试,比如登录, 支付等。上线前跑跑
baby0w0
2025 年 8 月 21 日
只有不经常变动的需求才适合写单元测试。
passion336699
2025 年 8 月 21 日
我们这也搞,每次开周会汇报进度,后端都会说,本周单元测试 0 。。。
zpvip
2025 年 8 月 21 日
想不到 Rails 团队的日常居然在别的团队就是一地鸡毛. Rails 团队的共识是发 Pull Request 一定要带测试, 而且 CRUD 测试也就是 Integration Test 中的 Request spec 根本不用自己写, 也用不 AI, 命令行就自动生成了. 然后再用 AI 补点其它测试, 比如说 Model 中自定义方法的 Unit tests 和 System specs, 重点 Test the behavior, not the implementation.

对, 我就是 V 站 2025 年尬吹 Rails 第一人.
GaliC2077
2025 年 8 月 21 日
@op351 点点点,手动测试,功能测试
GaliC2077
2025 年 8 月 21 日
@Biggoldfish 合并代码,只要代码 review 就行了。如果是大项目,大家一起 review ,小迭代是 leader 审批。
snowlyg
2025 年 8 月 21 日
@ipwx 哈哈,go 写 web 项目是这样的,我还用 httptest 专门封了一个 api 测试的项目自己用,集成了迁移之类的功能。
way2create
2025 年 8 月 21 日
建议直接把测试全裁了 让开发兼测试 管开发怎么测 降本增效了 这估计是你们领导要的
GaliC2077
2025 年 8 月 21 日
@jjwjiang 大佬还是你看得清楚啊。下面一堆说用 AI 的,但是没有抽象,神仙来了都写不了 UT 别说 AI 了。
第二点,其实我感觉就是上面要干掉测试组的一些名头。从今年开始逐步减少测试介入,p0 下项目推行开发自测....
ccover
2025 年 8 月 21 日
跟我司一样,轰轰烈烈的搞单测,还想把测试团队全部干掉(降本增效),还说什么微软都没有测试。
我没懂的是,测试工作量没有消失,只是转移,而且从测试转到开发(一般来说成本更高了)。
再就是搞单测要 mock 所有其他类的方法、造场景、验分支、还要 debug 为什么没进去或者不符合预期(非 bug 类的),还得 CR (对,单测也要 cr ,评估是否有效单测),结果单测花费的时间往往比开发时间多出 2 倍以上,还不能保证所有单测通过就能上线,还需要走测试(串流程等)。
最终结果是折磨大家一年后不了了之了
zerovoid
2025 年 8 月 21 日
技术部需要使用“阳奉阴违”之计,所有开发排期都拉长报呗,
领导想降本增效吗,实际结果就是成本反而增加,效率也下降了,
到时领导自然会撤销这个规则。
GaliC2077
2025 年 8 月 21 日
@qbmiller #23 现在 p0 项目,测试会介入写测试用例,开发来测试。p0 以下的用例,测试不介入,不给测试用例,开发自测。具体质量,完全看开发自测效果了。

其实以前无论项目大小是测试写测试用例,测试帮忙测试。但是今年开始测试不招人了...
wymisgod
2025 年 8 月 21 日
换个思路,不开测试,裁开发,看 LOC 去裁开发怎么样,也能降本增效
HelloWorld23333
2025 年 8 月 21 日
不能增加人员的话,就开掉 1 个测试或者 1 个开发。招一个写 go 的新人(女)专门做白盒测试(写代码测试)。
GaliC2077
2025 年 8 月 21 日
@baby0w0 大家反对的点也在这里,特别是使用 sqlmock ,改了数据库方法,还得改测试的 sql 的语言,像我们这种每周不断迭代功能的业务功能上,根本经不起折腾
udisyue
2025 年 8 月 21 日
@GallifreyCAR 单元测试只能保证你的代码段没问题,业务流程、需求偏离这些一点都不可能覆盖到。微软没测试,首先你老板要不要看看 windows 现在系统更新是个什么鬼样子,让他搜搜 win10 更新那些鬼故事

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

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

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

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

© 2021 V2EX