在 Angular 中引入 Jest 进行单元测试
为什么要从 Karma 迁移到 Jest
用 Karma 在项目中遇到了坑
最近新换了一个项目，去的时候项目已经做了两个月了，因为前期赶功能，没有对单元测试做要求，CI/CD 的时候也没有强制跑单元测试。所以虽然有用 Angular CLI 自动生成的测试文件，但是基本上都是测试不通过。
项目做久了，人员变动多，新来的成员对之前的业务逻辑不清不楚，稍不注意就会破坏之前的功能；业务复杂了，随便增加或者修改一点点功能都可能引起不易被察觉的 BUG。作为一个敬业的开发，不上单元测试怎么行。所以，就有了一个修复已有单元测试的任务。
修复已有测试文件的思路很简单：写个 TestingModule 把常用的依赖 mock 掉，再引入到需要的文件中就行了；不常用的依赖，在各自的文件中 mock 掉就好了。
然而实际操作起来的时候，Karma 早早挖好坑等这了。有些测试文件单跑没有问题，整体跑得时候就报错，测试结果及其不稳定；karma 的报错信息又特别难读懂，很多时候根本定位不到到底是哪里出了问题。再加上 Karma 需要先把 Angular 应用编译之后再在浏览器中跑测试，整体时间也比较慢，修复的过程一直处于抓狂的边缘。
整体测试跑起来的时候难以定位测试出错的定位，怎么办呢，那就让跑整个测试的时候各个文件之间也没有依赖可以单独跑好了，所以就想到了 Jest。实践证明，在 Angular 中， Jest 大法也非常好使。
Karma 和 Jest 的对比
前面也说过了，在修复测试的过程中，karma 遇到了各种各样的问题。归结起来大概就是：
- Karma 需要先把 Angular 应用整体编译之后再在浏览器中跑测试，跑测试的时间比较长；
- Karma 测试结果不稳定（很可能是因为异步操作引起的），单个文件和整体测试时的测试结果不一致；
- 报错信息模糊不清，无法定位问题。特别是在有大量测试需要修复的情况下，难以定位问题的根本原因。
那么对比而言，Jest 在上面这些方面都有很好的表现：
- 不需要整体编译，可以单文件测试
- 测试结果稳定
- 报错清楚，易于定位问题
除了这些，Jest 还有的好处有：
- 开箱即用，基本算是全家桶，包含了测试需要的大部分工具：测试结构、断言、spies、mocks
- 直接提供了测试覆盖率报告
- 快照测试
- 非常强大的模块级 mock 功能
- watch 模式仅仅测试和被修改文件相关的测试，速度非常快
迁移
第一步，你需要相关依赖包：
npm install --save-dev jest jest-preset-angular @types/jest其中：
- jest – Jest 测试框架
- jest-preset-angular – jest 对于 angular 的一些通用的预设置
- @types/jest – Jest 的 typings
第二步，你需要在 package.json 中对 Jest 进行配置：
"jest": {
"preset": "jest-preset-angular",
"setupFilesAfterEnv": ["/src/setupJest.ts"]
} 其中，preset 声明了预设，setupFilesAfterEnv 配置了 Jest setup 文件的地址，可以包含多个文件，这里设置的是项目根目录下的 src/setupJest.ts。
第三步，在 src 目录下创建上一步中设置的 setup 文件 setupJest.ts
import 'jest-preset-angular'; // jest 对于 angular 的预配置
import './jestGlobalMocks'; // jest 全局的 mock第四步，在 src 目录下创建 jestGlobalMocks.ts 文件，并加入相关的全局的 mock，以下是一个例子：
const mock = () => {
let storage = {};
return {
getItem: key => key in storage ? storage[key] : null,
setItem: (key, value) => storage[key] = value || '',
removeItem: key => delete storage[key],
clear: () => storage = {},
};
};
Object.defineProperty(window, 'localStorage', {value: mock()});
Object.defineProperty(window, 'sessionStorage', {value: mock()});
Object.defineProperty(window, 'getComputedStyle', {
value: () => ['-webkit-appearance']
});可以看到这个例子中 mock 了 window 上的对象，这是因为 jsdom 并没有实现所有的 window 上的对象和方法，所以有时我们需要自己给 window 打个补丁。
在这里 mock localStorage 是可选的，如果我们在代码中并没有使用。但是 mock getComputedStyle 是必须的，因为 Angular 会检查它在哪个浏览器中执行。如果没有 mock getComputedStyle，我们的测试代码将无法执行。
接下来，我们就可以在 package.json 的 script 中配置 test 的命令了：
"test": "jest",
"test:watch": "jest --watch",其中 test 只跑一次测试，test:watch 可以检测文件变化，跑当前有修改的文件的相关测试。
此时，在命令行中运行测试命令，就应该能够顺利把测试跑起来并通过了。如果没有通过，可能是因为我们在 src/tsconfig.spec.json 中的 file 配置中有 test.js 的配置，这是 Karma 的 setup 文件，删掉这行配置并删除对应的文件，(src/tsconfig.app.json 中出现的 test.js 也可一并删除)，重新跑一遍测试命令：
npm run test至此，Jest 测试环境就算顺利搭建好了。如果你对代码有洁癖，接下来，你还可以删除 Karma 的相关代码，将测试全部转为 Jest。
删除 Karma 相关代码
-
删除相关依赖包（@types/jasmine @types/jasminewd2 jasmine-core jasmine-spec-reporter 因为在 e2e 测试中有使用所以不能删除）：
npm uninstall karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine karma-jasmine-html-reporter - 删除文件
src/karma.config.js - 删除 angular.json 中 test 的配置
-
src/tsconfig.spec.json中compilerOptions.type的配置移除 jasmine, 加上 jest。
至此，你已经删除了所有与 Karma 相关的代码。你甚至还能将测试断言换成 jest 的风格。
查看最后生成的代码库和相关文件配置
参考：