请教下各位大佬 关于单元测试的问题

2021-03-10 10:33:21 +08:00
 www5070504

最近遇到几个不知道如何解决或者没有方向的问题 想请教下各位同仁

一是各位平时写代码的时候会写单元测试么, 或者现在写单元测试的人还多么. 现在为了快速上线, 我这里基本没写过单元测试,各位平时是怎么做的呢.

二是在单元测试中不知道各位有没有遇到过无法断言的情况, 比如我一个函数会生成一些二进制数据, 我不知道如何断言这个函数产生的结果是合法的数据. 或者比如一个函数产生一些网络数据包, 但是断言的时候没办法进行比较,因为返回值是不容易预测的.

求各位指教,谢谢各位啦

5628 次点击
所在节点    程序员
67 条回复
imdong
2021-03-10 13:46:47 +08:00
有同样的疑惑:测试一般是分两种吧,一种是单元测试,一种是功能测试。

我理解的测试应该是避免新增加的改动导致原有的逻辑被改变了而不知道(越改 BUG 越多)。

但是看到楼上的说法:只喂正确的数据,得到正确的结果。

意思是对于异常流程,不需要写测试了么?

比如发布一篇文章:

对于内容过长或过短,选择的分类或类型错误,时间不正确这类情况等。。。

求大佬指点,
iyaozhen
2021-03-10 14:00:35 +08:00
首先单测是肯定有用的,是利大于弊的

1. 大公司是有要求的,这么说吧,优秀的项目都是有单测的。当然为了覆盖率一刀切的假单测是没有任何作用的
2. 前面有人说了。还有一个就是要区分单元测试和集成测试,我见过极端的,全部用集成测试代替单测


@supermao
「写的单元测试都是你能想到的并且不会错的」
写的单元测试都是你能想到 这个没问题,不管什么测试都是这样的。但单测还有个作用就是重构的时候,不管方法内部改动多大,之前能满足的输入输出,重构后也要能满足
「并且不会错的」这个不对,单测并不是这个方法完全写好后,再写单测,一般是一边写逻辑,一边加单测代码。甚至先把单测代码写好。而且这个方法开发过程中、以及后面的重构,都可能出错,这样单测就能搂住了。有一个共识:发现阶段越早的 bug 越好修复
www5070504
2021-03-10 14:04:00 +08:00
@iyaozhen 讲的很清晰 我有点明白了 单测是真正的逻辑 目前的代码和未来重构出来的代码都可以理解为类似单测逻辑的子类
www5070504
2021-03-10 14:06:31 +08:00
是这个意思么 自己感觉好像懂了点
iyaozhen
2021-03-10 14:07:02 +08:00
@imdong 要把单元测试和功能集成测试区分开

比如你有一个方法是判断输入参数的,就需要对这个方法进行单测
「意思是对于异常流程,不需要写测试了么?」异常流程肯定也需要,所以单测里面有个重要的概念:分支覆盖率
简单来说就是方法里面的各个 if else 是否都覆盖了

但话说回来,对于单测来说这是可预知的异常分支,比如一些其它异常请求参数非常大,tomcat 就报错了、mysql 网络异常等这些不在单测范畴
iyaozhen
2021-03-10 14:09:54 +08:00
@www5070504 嗯嗯 需要多多实践。
本着减少 bug 、可维护、高质量代码去做就行,单测只是一个手段。为了单测而单测也不行
CodingNaux
2021-03-10 14:23:26 +08:00
单元测试不好写,可能是代码结构写的不好
测试代码要足够简单,断言合理
mock 掉外部依赖,外部依赖的测试单独测
盲目追求高覆盖率会很累(前端业务代码 要求 80%的覆盖率,后补单元测试的时候,写的想吐)
遇到 bug 是要针对补单元测试的

但,
突然发现,测试覆盖度和合理的测试断言是两回事,达到覆盖度指标就能过 ci 。。。。。逃
ahsjs
2021-03-10 14:54:51 +08:00
会写,已经成习惯了,不过没那么全和细致。
lzlee
2021-03-10 15:02:16 +08:00
感谢大佬们的分享
我想问下, 有没有在大厂工作的大佬

你们的单元测试率, 真的要到 80% 吗
GeruzoniAnsasu
2021-03-10 15:05:23 +08:00
@imdong 我的说法只是写单元测试的思路 hint 而已,并不是单元测试的方法论……

当你不知道你写的这坨代码从什么角度写测试时,用我提到的方法来构造一些可递归拆解的 “单元”,拆到你自我感觉足够独立足够单元后,就好对它们进行测试了

实际上在写的时候,肯定要根据实际情况考虑正负分支、边界异常条件什么的。我是觉得到写 assert 的时候自然会多想到一些条件来 assert 的,不用说太细
zhuweiyou
2021-03-10 15:10:27 +08:00
不写
yamasa
2021-03-10 15:14:44 +08:00
ut 就是把 mock 的概念吃透,然后勤练就慢慢熟悉了。
当然是有用的,用 mock 解决掉复杂的外部依赖,专注于每个函数自己的实现正确性,这不重要吗?你能保证你写的复杂业务逻辑每个 corner case 都覆盖了?我甚至遇到好些 corner case 靠自己 e2e 或者集成测试根本没法触发的,这种上了生产就是不定时的雷,ut 在这些时候非常重要。
idra
2021-03-10 15:17:52 +08:00
作为一个测试,我职业生涯 7 年+以来,看见真正做单元测试的团队只有一个。团队大佬负责写单元测试,然后丢给小弟去实现。个人认为这才是真正教科书上的开发方式:面向单元测试开发。
yiqiao
2021-03-10 15:27:56 +08:00
敏捷开发,能通就行。剩下的交给客户当黑盒测试了🐶
moonrailgun
2021-03-10 15:29:43 +08:00
会写一些纯函数的单元测试。

这样就不用通过主动运行人肉调试了
iyaozhen
2021-03-10 15:37:44 +08:00
@lzlee 能水到 80% (逃
uselessVisitor
2021-03-10 15:47:34 +08:00
看项目的紧急程度
CitizenR
2021-03-10 15:59:23 +08:00
@idra 所谓 TDD 是也。好处很多,难度不小。
www5070504
2021-03-10 16:06:26 +08:00
@idra 这个流程确实是不错的啊 我刚入行的时候部门经理也是写一些核心的东西然后让我来丰富的 感觉还真挺好的
www5070504
2021-03-10 16:06:51 +08:00
@yiqiao 哈哈我现在就在这条路上狂奔

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

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

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

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

© 2021 V2EX