前言:在生成单测代码积累到一定数目之后,我发现每次执行运行命令的时间都特别慢,这让我开始思考如何对Jest进行性能优化
从上图可以看到,最影响 Jest 性能的有 3 个地方:
-
生成虚拟文件系统
-
多线程执行测试任务
-
转译 JavaScript 代码
虚拟文件系统
上一篇提到了可以使用Jest热更新提高效率,但如果要在热更新时修改文件,脚手架都要遍历一次项目文件,非常损耗性能。
为了解决这个问题,Facebook 团队就想到了一个方法 ------ 虚拟文件系统。原理是在第一次启动时遍历整个项目,把文件存储成Map的形式, 之后若对文件进行改动,只需增量地修改这个Map 。 这个工具便是上一篇中提到的Haste Map。这种思路不仅可以用于热更新场景,还能应用在所有监听文件改动的场景。但这个方法在执行第一个测试用例时的性能无法优化。
多线程
Jest 还有一个非常强大的功能,利用 Node.js 的 Worker 开启多个线程来执行测试用例。对于一些大型项目来说,这能提升不少效率,但对于非大型项目而言多线程反而会加大开销。
Jest 默认最大的 Worker 数是 CPU 数 - 1
。其中的 1
用于运行 jest-cli
, 剩下的都拿来执行测试用例。若我们不对maxWorkers
进行配置,系统会默认使用最多的Worker,这种情况下执行少量的测试反而会变慢,因为每开一个线程都需要额外的开销。
所以若测试数量不多的情况下,我们可以考虑单线程,在jest.config.js
上进行配置:
java
// jest.config.js
module.exports = {maxWorkers: 1}
同时尽量不写一些耗时的操作,比如不要加 setTimeout
,n
个 for
循环等。
另外也有相关资料指出,在不同的电脑上使用单线程还是多线程更优也会有所差异,需要因人而异设置Worker数量。
文件转译
最后一个性能优化点就是转译速度,Jest 会边执行 测试用例 边转译 JavaScript 。
思考:既然 Jest 刚开始遍历项目来生成虚拟文件系统,为什么不把转译的工作也做了呢?
对于很多业务项目来说,测试并不会很多,如果将项目的文件都转译一次,会把很多没用到测试的业务代码也转译,反而会加大开销。
现如今 JavaScript 的转译器有很多种,不仅可以用 tsc
和 babel
来转, 还能用别的语言写的转译器 swc
以及 esbuild
来转。
以swc
为例@swc/jest (opens new window, 先安装依赖:
kotlin
npm i -D @swc/core@1.2.165 @swc/jest@0.2.20
然后在 jest.config.js
里添加:
java
module.exports = {
// 不用 ts-jest
// preset: "ts-jest",
transform: {
// 使用 swc 转译 JavaScript 和 TypeScrit
"^.+\.(t|j)sx?$": ["@swc/jest"],
// 静态资源 stub 转译
".+\.(css|styl|less|sass|scss|png|jpg|ttf|woff|woff2)$":"jest-transform-stub",
},
}
总结
通过Jest 的整体架构,其中有 3 个地方比较耗性能,优化方式如下:
- 生成虚拟文件系统,把文件存储成Map的形式
- 合理使用多线程,当测试用例数目较少时可以减少Worker数量
- 文件转译:使用
esbuild-jest
、@swc/jest
等其它高效的转译工具来做转译