哈喽,大家好,我是海怪。
前段时间一直在给公司项目引入 Jest ,这过程中学到了不少东西,也查了很多相关资料。最后编写了一本小书《 Jest 实践指南》, 希望能帮助到想了解和学习前端测试的朋友。
Jest 看似很简单,就像很多博客写的那样:
expect(sum(1, 1)).toEqual(2)
然而在真实业务中,写出一个好测试的难度并不低。我总结了一下写测试的几个难点:
不会配置。 Jest 的上手文档非常简单,甚至不需要配置。但真实情况是只要一个配置没配好,所有测试都跑不起来。测试不像开发,代码有问题可以慢慢调, 而是一个 0 - 1 游戏,不是成功就是失败,挫败感非常强。
不知道要怎么 Mock 。 这个绝对是经典中的经典。虽然官方文档有教程,但是真实的业务往往不是那么理想,远比文档要复杂得多。
不会构造测试用例。 刚接触测试时,很容易把做业务那套 “实现 XXX 功能” 的想法代入测试。但测试的重点不在于实现功能,而是构造用例。
没有测试策略。 上面是 “技” 的难点,测试还有 “术” 的难点。闷着头肝测试并不高效,使用合适的测试策略远比写 10 个测试用例重要。
上面这些问题很容易让人写出难以维护和复杂的测试。只要业务一改,不仅要维护业务代码还要维护测试代码。 这时,你不禁感叹:“测试真浪费时间”,最终放弃写测试,直接开摆。
好的测试会让你获得很高的代码信心,而不好的测试则会严重拖垮项目开发。所以,大家所厌恶的不应该是测试本身,而是那些维护性差的测试。
目前国内关于前端测试的内容非常糟糕,在我查找资料过程中就没有一次是不坎坷的。首先是 Jest 的官网就不给力:
先不说翻译的正确性如何,单看这中文的内容就让人没有想看下去的欲望,真希望 Jest 能找稍微专业一点的人来做翻译。 由于官网的中文翻译做的实在太烂,遇到问题几乎在中文社区是找不到的。
再来说国内关于测试的文章,我总结有三类:
expect(1 + 1).toEqual(2)
小例子不是说这些文章不好,只是这些文章大多数停留在最初级,看完还是不会怎么写测试。就现状来看国内测试社区是有进步的,至少有不少人在写第三类了,要知道以前基本只有第一类文章。
终于,我看到了 React Testing Library 作者 Kent C. Dodds 的 博客 。
他写了很多关于测试思路的文章,每一篇都非常精彩。受他的启发,我觉得有必要把这些思想和技巧分享出来,最终形成了这本小书。这本小书要解决的就是 “怎么做” 这一步。
此次教程主要分享测试的思路为主,虽然以 React 为主要技术栈,但使用其它技术栈的读者依然可以流畅阅读。
本教程是我结合了自身实践、Kent C. Dodds 文章、StackOverflow 、Github Issue 以及别的博客最终总结出来的一套实践指南。
小书包含 3 部分:
我知道很多人看到这个贴子依然对测试嗤之以鼻,可能觉得写测试就是扯淡、浪费时间的,也可能你已经对国内的 “短平快” 失望了,这个我完全能理解。
但我相信总有人愿意写测试的,我希望在他们学习如何写测试时能给一个方向和引导。
1
snoopyhai 2022-05-20 09:37:34 +08:00
太好了, 感谢
|
2
yaphets666 2022-05-20 09:45:51 +08:00
点赞,前端测试方面的资料真的蛮匮乏的
|
3
wxrbw555 2022-05-20 09:52:13 +08:00
目测 08 粉丝
|
5
Kaier 2022-05-20 10:00:22 +08:00
star 了
|
6
wequart 2022-05-20 10:01:05 +08:00
棒!!
|
8
lneoi 2022-05-20 10:10:17 +08:00
借楼问个问题, 之前测试 cli 工具, 想测试传入参数是否按预期走到正常逻辑内, 但内部是直接调用 process.argv 获取参数的, 没找到模拟方案, 这个场景要如何写测试用例呢?
|
9
yunyuyuan 2022-05-20 10:13:10 +08:00
🐂,先 star 了,测试这块接触的不多
|
10
cburt 2022-05-20 10:15:36 +08:00
太棒了!!!已 star
|
11
Ccbeango 2022-05-20 10:17:09 +08:00
强!
|
12
Haixiang OP @wxrbw555 你是怎么看出是 08 粉的?文章里有些话很想用“受不了直接投降”,一直控制住自己 08 化,怕大家不知道这个梗,哈哈
|
13
Haixiang OP @lneoi Mock process.argv 属性:Object.defineProperty(process, 'argv', { value: xxx })
|
15
Haixiang OP @yaphets666 是的呢,感谢支持~
|
17
a90120411 2022-05-20 13:09:28 +08:00
粗读了一下,感觉很工整,支持一下!
|
18
palxie 2022-05-20 13:43:10 +08:00
牛, 以前做 test 时, jest 啃了好久, 现在一定好好看看
|
19
dany813 2022-05-20 14:10:10 +08:00
收藏
|
20
a4854857 2022-05-20 14:12:53 +08:00
谢谢!
|
21
Terry05 2022-05-20 14:13:32 +08:00
很棒的书!
|
22
varzy 2022-05-20 14:15:00 +08:00
正好需要,感谢分享!
|
23
huajieyu 2022-05-20 14:15:33 +08:00
感谢分享
|
24
s5s5 2022-05-20 14:55:17 +08:00
非常感谢,楼主辛苦了,Star 送上
|
28
Hilong 2022-05-20 15:25:47 +08:00
点赞👍
|
30
hamsterbase 2022-05-20 16:12:28 +08:00 1
可以试试看 vitest 。
1. API 和 jest 几乎一样,迁移不需要改原先的代码 2. 自带 ts 支持,不需要 ts-jest 3. 速度快好几倍 |
31
v23xowen 2022-05-20 16:27:04 +08:00
支持~
|
32
yazoox 2022-05-20 16:55:04 +08:00
@hamsterbase 这么牛 B 么?支持度怎么样?不会过几年没有维护吧?
jest 好像是 facebook 支持的? |
33
hamsterbase 2022-05-20 17:15:26 +08:00 via iPhone
|
34
wxrbw555 2022-05-20 17:59:30 +08:00
“这里我们还不忘搞点花里胡哨,引入了 src/components/AuthButton/styles.less:”
“好,现在我们一个一个问题来看。写完上面的代码后,TS 首先受不了报错:” 这两句话在"Less 的引入问题"附近,太像了😂 |
35
liugezhou 2022-05-20 18:08:04 +08:00
先码后看,最近也是在搞 jest
|
36
zhw2590582 2022-05-20 20:37:46 +08:00 via iPhone
一旦涉及到 dom 的,都不好写测试用例
|
38
Haixiang OP @hamsterbase 可以,可以尝试点新的
|
40
Haixiang OP @zhw2590582 对的,最好用更贴近用户的真实行为来做测试
|
42
morize 2022-05-20 22:30:12 +08:00
上个月一直在做这方面,真实业务场景要把单测跑起来就要先构造海量的数据。业务逻辑纯 js 还算简单。但涉及到视图层,尤其是复杂的组件,真的没动力,并不能感到带来代码质量提升,反而如果为了测试要破坏原有的代码结构,得不偿失,不如不做。
|
43
Haixiang OP @morize 如果是太复杂与业务联动太高的业务,那不应该做单测,而是集成。单测在业务中不太常用,原因是单测比较关注逻辑和数据,造数据和关注逻辑又是一个很痛苦的过程,而集成偏向于关注交互。当然,如果写测试的成本大于测试带来的收益,也可以不做。
|
44
tonytonychopper 2022-05-21 10:43:01 +08:00
支持,正好缺这方面的资料,感谢!
|
45
Loserzhu 2022-05-21 13:25:15 +08:00
感谢分享
|
46
reiji 2022-05-21 16:57:46 +08:00
感谢!我也一直不知道如何很好的写测试,学习一下
|
48
lfr502 2022-05-21 18:58:17 +08:00
cool
|
49
aaronlam 2022-05-25 11:54:40 +08:00
在短平快的业务开发下,的确很少接触到单测,先学习一波
|