Jest性能优化 - 技术栈

前言：在生成单测代码积累到一定数目之后，我发现每次执行运行命令的时间都特别慢，这让我开始思考如何对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 等其它高效的转译工具来做转译