本文介绍在 icejs 中使用 jest 和 react-testing-library 进行单元测试时的初步探索和注意事项。
前提
想用 JEST,import React from 'react'
必须写。我也不知道为啥,即使打开了 jsx-runtime
,也要写,否则 jest 就报错给你看。
指定文件的单元测试
由于 umijs 里做了封装,所以运行指定文件的单元测试,如果测试文件名为 MyName.test.tsx
只需要:
yarn test MyName
而 icejs 中,首先 jest 需要单独安装,另外文件名位置需要完整一点,文件后缀不可缺少:
yarn test **/MyName.test.tsx
组件 快照测试
对于快照测试,正常来讲就两步走:
一是安装 react-test-renderer
这个包,然后代码就是:
const dom = renderer.create(<BasicList />).toJSON(); expect(dom).toMatchSnapshot();
但其中要注意:我目前安装的 icejs 版本是 v2.6.4,它的 dependencies 中 React 的版本是 17.0.2,而如果直接 yarn add react-test-renderer -D
的话,它按的似乎是最新版 18.x。在后续使用中会出现问题,所以安装时使用:
yarn add react-test-renderer@17.0.2 -D
或手动修改版本号再重装依赖。
另外,我在 Win10 下使用 jest 来做快照测试时,jest 报一个路径的错误。随后我转用 Docker,在 Debian 容器中开发,Linux 下不报错。
使用 useRequest 的组件 快照测试
如果组件内使用了 useRequest,则 jest 要配置为 js-dom 模式才能进行快照测试。两种方法处理:
1. 在根目录创建 jest.config.js
,在其中写入:
module.exports = { testEnvironment: 'jsdom', };
2. 在 package.json 中,写一个 jest 项,把上面的 testEnvironment
写入。
使用 react-testing-library
直接安装使用 react-testing-library
,使用时报:
Could not locate module react-dom/client mapped as: /usr/src/app/node_modules/react-dom/$1.
依然是版本问题,默认安装是 13.x,降为 12.0.4
yarn add @testing-library/react@12.0.4 -D
更新快照的命令
更新快照不是简单的加 -u,命令需要这么写:
yarn test --jest--updateSnapshot
我尝试过:
npm test -- -u yarn test -u yarn test -- --jest-u
等等各种写法,都不好使。
当然,后面这一长串有点难打,所以写了一个 script 命令到 package.json 里:
"test-update": "icejs test --jest--updateSnapshot",
牢骚
最近在用国产 icejs 框架,刚按好就直奔单元测试的使用而去,这是我判断框架好坏的标准。
我基本想放弃蚂蚁的 umijs,因为我觉得它封装的太严重。当然,在开始使用 umi 前,有好心网友就提醒过我,所以我心理一直有个底,就是这东西只能做跳板。
后来当我想在 umijs 上添加点 lint 规则时,我崩溃了,我甚至不想回忆,我只能留下一句话:我是很菜鸟,智商很低,但是这也太欺负人了。
现在使用 icejs,总体感觉跟 umijs 差不多,不过感觉还是强一些的,总体认为它封装的没有 umi 狠。其实封装是好事,不用多配置,上手快。但是封装也会同样造成不灵活、不开放。若更新不及时,所造成的影响是菜鸟难以想象的。icejs 虽然也封装,也封装的不浅,但我觉得比 umi 还是浅一些的。这样出现问题后,研究起来可能没那么复杂,至少单元测试是这样。
我偏爱 icejs 还有另外两个原因,一个是我觉得 formily 不错,而 icejs 网站上有 formily 的介绍。另外我觉得阿里的人应该还靠谱,至少认真、专注。而反观 umi 的团队,我觉得可能不太理想。
但是国内还真是,不写单元测试成为习惯。作为一个前端白菜,单元测试上手真是很难。umijs 是这样,icejs 也是这样,文档普遍不适合新手,我很遗憾,很遗憾。