有没有大佬告诉我单元测试用在哪里?这个问题困扰我好久了

2025 年 7 月 18 日
 tiRolin

在学习的时候就经常听人说单元测试很重要,但是我每次看单元测试我都没搞懂这跟我手动 API 测试有啥区别?我感觉单元测试还更麻烦了,因为单元测试还需要自己创建测试数据自己测试核心逻辑和业务逻辑,我手动 API 测试不也能走一遍吗?然后说是单元测试更全面,但是我看单元测试的用例也是要我手写啊,这两个真有区别吗?

而且单元测试比手动调 api 测试麻烦好多,比如说我现在在做的菜单树功能,我不太理解单元测试我就让 cursor 帮我生成,他框框一顿写就已经有四百行代码了,这要是人力来写这不是写单元测试的时间都要比写功能本身还要花更久的时间了吗?

是不是实际开发的时候其实大多数简单功能,比如说我的菜单树是不会进行单元测试的,只会做简单的自测,而对于确实很复杂有必要长期维护的核心功能比如支付这种才对做单元测试?

6210 次点击
所在节点    Go 编程语言
59 条回复
manami
2025 年 7 月 18 日
单元测试可以在启动的时候就知道通不通过,或者通过率是多少。手动 API 测试没有量化,也不自动
xwayway
2025 年 7 月 18 日
方便重构,方便他人接手。

如果有单测,且覆盖较为完全的话,完全不用担心重构之后漏测了哪个 case ,也不用担心后来人接手改代码把哪个特殊场景漏掉了。
chendy
2025 年 7 月 18 日
用于核心模块重要模块,便于在修改之后确定影响
换句话说就是普普通通的 crud 犯不上
tiRolin
2025 年 7 月 18 日
@chendy 大佬,我悟了。我就说怎么经常很多时候感觉单元测试完全是累赘,这是因为不是核心模块啊
zhnd18
2025 年 7 月 18 日
我觉得最重要的是开发流程的改变,可以了解一下 TDD 开发
iyiluo
2025 年 7 月 18 日
代码功能怎么证明功能正常?就是单元测试,起码能给程序员一些信心,单元测试覆盖的越广,底气就越足。否则你上线都战战兢兢,生怕哪里出问题
midsolo
2025 年 7 月 18 日
理想中:项目单元测试覆盖率要在 90% 以上
现实中:先上线,后面再补单元测试跟文档
Maboroshii
2025 年 7 月 18 日
如果要做单元测试,需要在写代码的时候就做好拆分。
毕竟很多业务代码是没办法做单测的,依赖一坨、耦合一坨
EthanDon
2025 年 7 月 18 日
1. 帮助你想清楚你的代码的边界条件,保持代码的健壮性
2. 需求开发完,运行一下单测,确保先前兼容,或者如果有挂了,说明边界条件变化了
3. 方便别人维护你的代码,也方便你自己过了很久以后来维护自己代码
4. 正如楼上所说,可单测的代码才是代码,单测都写不了,依赖、耦合毛病一堆,屎山一坨

想象一下,你现在要用一个第三方库,但是有个功能你不知道怎么用,如果 owner 做的好,维护所有情况的单测,你只需要对着看,运行一下,你就知道这个功能的预期效果了。
oaa
2025 年 7 月 18 日
当你觉得写单元测试很麻烦的时候,说明你想测的逻辑很难触及。这本身就是一个坏味道了。
想象一下,你写的任意业务逻辑,都可以很方便的被触及到,这不比手动测爽多了。
lyxxxh2
2025 年 7 月 18 日
小项目,我都是拿来当 "订单调试",也就订单有些逻辑。
手工点击:
1. 需要十几秒,还可能出错,
2. 手累,不太想动 (这应该是主要)

复杂的系统,比如 erp,就光一个创建订单。
商品库存 库存 库存流水 对账 欠款... 都要肉眼去看是否正确,看到想吐。
直接断言数据怎么样,断言失败再去看。
而且后续修改代码,运行下测试,也知道各个功能正常。
cxe2v
2025 年 7 月 18 日
@dlmy 你这个现实中是想象的,实际的现实中:上线后,跑步进入下一个需求,上线了的绝不会再给资源让你补测试跟文档
EthanDon
2025 年 7 月 18 日
@EthanDon
再想象一下,老板让你给一个很复杂的模块加个新功能,你吭哧吭哧搞完了,要交付了,怎么测试?通过 API 自己模拟各种情况吗?可以这么搞,也可以写成单测。
测完了,你突然想起来这个模块以前就很复杂,有很多情况要回归测试,怎么办,再挨个挨个点 API 吗?这时候有单测的话,你只需要 make test 就结束啦
redbule
2025 年 7 月 18 日
单测需要良好的程序结构。用的时候嫌弃 java 依赖注入,接口多,测的时候才知道作用。
软件工程没有捷径,一面简单了,另一面就要承受代价了
chairuosen
2025 年 7 月 18 日
单测的测试数据是 hook 进去的假数据,而不是真的读库。不依赖环境就能单独跑
layxy
2025 年 7 月 18 日
单元测试一方面用于自测,一方面用于 cicd 流程的卡点,即单元测试覆盖率和结果不达标无法进行某些操作,实际上中间件等偏技术类型的项目单元测试体验比较好,但是在业务场景,尤其是涉及到多个 rpc 调用时,单元测试的心智负担和工作量很大,不但要 mock rpc 服务,还要 mock 数据库操作,而且这样的单元测试覆盖并不全,仅能验证你的代码逻辑没有问题,但是不能验证整体功能没问题
tf2
2025 年 7 月 18 日
但是我每次看单元测试我都没搞懂这跟我手动 API 测试有啥区别?


没区别。单元测试 就是把你手动 API 测试,持久化成一个调用,可以重复执行。
Rickkkkkkk
2025 年 7 月 18 日
单元测试的意义在于,另外一个人来开发,他搞完之后想看看之前功能是不是对的,总不能手动调 api 的方法测吧。
wjfz
2025 年 7 月 18 日
论结果,单测和手动点 API 都是为了保证接口正常运行,但还是有区别的。

1 、单测不需要在本地启动 server 服务,有时候项目大了,在本地起服务是很麻烦的事情。
2 、单测可以一次写好到处运行,开发阶段自测,流水线以运行,其他同事可以运行。
3 、不会产生脏数据。
4 、高效,能并发同时跑很多单测,但是手动点 API 就不能。
5 、单测是基于代码和业务的,目前很多 AI 生成单测都不好用。
ThinkCat
2025 年 7 月 18 日
单元测试是为了保证功能符合预期,并且在长久的迭代中,仍然保证兼容,功能符合预期。
比如这段功能,不管怎么变更代码,只要功能没有发生变化,以前的单侧输入 abc ,返回或者表现上就应该是 xyz 。并且单测最好是测最小功能单元,是可重复执行的,依赖的数据要 mock ,不随着外部环境的变化而变化

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

https://www.v2ex.com/t/1146114

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

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

© 2021 V2EX