前言：在生成单测代码积累到一定数目之后，我发现每次执行运行命令的时间都特别慢，这让我开始思考如何对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上进行配置：
// 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， 先安装依赖：
npm i -D @swc/core@1.2.165 @swc/jest@0.2.20
然后在 jest.config.js 里添加：
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等其它高效的转译工具来做转译
原文链接：https://juejin.cn/post/7328250113792852020 作者：333333
