icejs v2的单元测试初探(飞冰)

本文介绍在 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 也是这样,文档普遍不适合新手,我很遗憾,很遗憾。

点赞