js 能在浏览器直接运行测试,那还需要 jest 吗

2022-07-04 10:37:30 +08:00
 yifan1719

正常工作中我好像没有遇到过必须要用 jest 等测试工具来测试我的代码运行的场景,

一般都是直接跑开发环境实时就能看到代码效果,包括 html/css 都是实时就能在浏览器中展示的,

简单的功能也可以在 vscode 上编辑好了,cv 到 chrome 控制台检验正确与否(当然,复杂的功能都是由简单的功能拼装起来的,所以对我来说没有复杂的功能 😜)

所以我很疑惑,jest 这类工具在什么场景中会有必须要使用的情况

2974 次点击
所在节点    程序员
17 条回复
wenzichel
2022-07-04 10:53:50 +08:00
写单测可以带来的好处:

1. 考虑更多额外的情况:有些功能,受限于数据的输入,不可能展示出所有的情况,那么在单测中,就可以用各种合理不合理的数据,来验证这个功能;
2. 保证安全性:出现一个错误的现象时,单测结果能保证当前这个功能点是没问题的,可以缩小排查范围;即使在重构时,也能知道这个功能是干嘛的,考虑了哪些状况;
otakustay
2022-07-04 11:49:34 +08:00
你这个模式,它自动化了吗,能改一行代码就跑 1000 个用例吗。没有自动化的情况下你确定你自己粘贴的这些用例覆盖了真正的代码修改影响面吗
yifan1719
2022-07-04 12:10:55 +08:00
@otakustay 我不清楚自动化测试用例的场景,所以才想问的,能具体展开讲讲吗?比如什么情况下要测试 1000 个用例
zhouyg
2022-07-04 14:03:57 +08:00
最简单方法是代码覆盖率和逻辑覆盖率都要达到 100%
Pastsong
2022-07-04 14:09:02 +08:00
单元测试不是为了让你代码能运行,更多的意义是:
- 你的代码在每个设计的条件分支、边界条件输出都是正确的
- 保护你的代码在重构中不会被影响到
cangcang
2022-07-04 15:21:42 +08:00
如果你不希望每次修改代码,都要手动测一遍之前的用例。那还是用 jest 比较好
passon
2022-07-04 15:24:09 +08:00
人工看覆盖不了所有场景啊
不过正常项目里面大家都不写单元测试
molvqingtai
2022-07-04 15:27:40 +08:00
你不能保证每次改动,都 100% 对原逻辑没有影响,不可能每次改动点手动重头手动测试一遍
ada87
2022-07-04 15:34:38 +08:00
我同样也认为前端浏览器环境的组件,完全没有必要单元测试,刷页面就行了,写用例又恶心,运行又慢,变化又快。

如果代码有与浏览器无关的通用方法,很有必要写,前提是你的代码结构粒度要清晰。
lscho
2022-07-04 15:36:59 +08:00
@yifan1719 你修改模块 A ,其他调用模块 A 的任何一个地方都有可能受到影响,手动怎么测呢?全部拉出来跑一遍吗
hamsterbase
2022-07-04 15:42:17 +08:00
先回答楼主的问题

如果测试的都是浏览器内的逻辑,的确不需要 jest 。可以使用浏览器里的测试框架。 比如说 https://karma-runner.github.io/latest/index.html

或者使用集成测试的框架 https://docs.cypress.io/

上面两个框架都是跑在浏览器的。



如果是纯 js 的逻辑,或者是代码里涉及到了 nodjs , 用 jest 、vitest 等框架也是极好的。

https://github.com/hamsterbase/hamsterbase/pull/1/files

举个例子。 我这个开源 SDK ,一共 800 行代码。
hamsterbase
2022-07-04 15:55:04 +08:00
测试框架主要由几部分组成


1. 测试框架: 主要用来提供测试的语法. 如 mocha

https://mochajs.org/

describe('Array', function () {
describe('#indexOf()', function () {
it('should return -1 when the value is not present', function () {
assert.equal([1, 2, 3].indexOf(4), -1);
});
});
});


2. 断言库: 主要用来写测试的断言 如 chai

expect(foo).to.be.a('string');
expect(foo).to.equal('bar');


3. 覆盖率工具: 主要是用来对代码插桩,或者是收集代码的使用情况。

可以看 instanbuljs 或者是 c8. 前者是插桩,后者是从 v8 收集数据。


4. mock 工具: 主要是忽略部分依赖。 使用 mock 的假依赖替换真实依赖。

https://www.npmjs.com/package/mm


jest 只是封装了上面这些工具。 其实你完全可以自己组装,开发出需要的库。
yifan1719
2022-07-04 16:29:28 +08:00
@hamsterbase 多谢大佬解惑,这么说比较能够解决我的疑惑,之前确实只是单独使用过你说的这几项中的一项,单独分开来讲我都能明白每一个工具的使用场景
yifan1719
2022-07-04 16:41:23 +08:00
@molvqingtai 但是我这样的话又涉及另一个问题了,就是我写的用例如果存在不完全覆盖是不是也就说明
1:我不够仔细(当然我无法保证我能做到仔细覆盖 100%覆盖)
2:用了 jest 等工具约等于没用,还是会存在不通过的场景
hamsterbase
2022-07-04 17:03:59 +08:00
@yifan1719

目前我推荐用 vitest

1. 速度快
2. 开箱即用。支持 ts


我个人建议以单测为主,集成测试为辅。 浏览器里的测试不太适合跑在 CI 上,速度也比较慢。


我自己写过最麻烦的 js 项目,每次就改几行代码,测试要跑几个小时。
ChefIsAwesome
2022-07-04 17:19:51 +08:00
需要用户操作的,除了表单验证,都没办法拿代码测。你要是写工具,写框架,写不跟用户交互直接相关的,你自然而然会去找测试方案。
yifan1719
2022-07-04 17:27:23 +08:00
@ChefIsAwesome 多谢大佬解惑

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

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

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

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

© 2021 V2EX