在 Angular 中引入 Jest 进行单元测试

在 Angular 中引入 Jest 进行单元测试

为何要从 Karma 迁移到 Jest

用 Karma 在项目中遇到了坑

最近新换了一个项目,去的时候项目已经作了两个月了,由于前期赶功能,没有对单元测试作要求,CI/CD 的时候也没有强制跑单元测试。因此虽然有用 Angular CLI 自动生成的测试文件,可是基本上都是测试不经过。
项目作久了,人员变更多,新来的成员对以前的业务逻辑不清不楚,稍不注意就会破坏以前的功能;业务复杂了,随便增长或者修改一点点功能均可能引发不易被察觉的 BUG。做为一个敬业的开发,不上单元测试怎么行。因此,就有了一个修复已有单元测试的任务。
修复已有测试文件的思路很简单:写个 TestingModule 把经常使用的依赖 mock 掉,再引入到须要的文件中就好了;不经常使用的依赖,在各自的文件中 mock 掉就行了。
然而实际操做起来的时候,Karma 早早挖好坑等这了。有些测试文件单跑没有问题,总体跑得时候就报错,测试结果及其不稳定;karma 的报错信息又特别难读懂,不少时候根本定位不到究竟是哪里出了问题。再加上 Karma 须要先把 Angular 应用编译以后再在浏览器中跑测试,总体时间也比较慢,修复的过程一直处于抓狂的边缘。
总体测试跑起来的时候难以定位测试出错的定位,怎么办呢,那就让跑整个测试的时候各个文件之间也没有依赖能够单独跑好了,因此就想到了 Jest。实践证实,在 Angular 中, Jest 大法也很是好使。html

Karma 和 Jest 的对比

前面也说过了,在修复测试的过程当中,karma 遇到了各类各样的问题。归结起来大概就是:git

  • Karma 须要先把 Angular 应用总体编译以后再在浏览器中跑测试,跑测试的时间比较长;
  • Karma 测试结果不稳定(极可能是由于异步操做引发的),单个文件和总体测试时的测试结果不一致;
  • 报错信息模糊不清,没法定位问题。特别是在有大量测试须要修复的状况下,难以定位问题的根本缘由。

那么对比而言,Jest 在上面这些方面都有很好的表现:github

  • 不须要总体编译,能够单文件测试
  • 测试结果稳定
  • 报错清楚,易于定位问题

除了这些,Jest 还有的好处有:web

  • 开箱即用,基本算是全家桶,包含了测试须要的大部分工具:测试结构、断言、spies、mocks
  • 直接提供了测试覆盖率报告
  • 快照测试
  • 很是强大的模块级 mock 功能
  • watch 模式仅仅测试和被修改文件相关的测试,速度很是快

迁移

第一步,你须要相关依赖包:chrome

npm install --save-dev jest jest-preset-angular @types/jest

其中:npm

  • jest – Jest 测试框架
  • jest-preset-angular – jest 对于 angular 的一些通用的预设置
  • @types/jest – Jest 的 typings

第二步,你须要在 package.json 中对 Jest 进行配置:json

"jest": {
  "preset": "jest-preset-angular",
  "setupFilesAfterEnv": ["<rootDir>/src/setupJest.ts"]
}

其中,preset 声明了预设,setupFilesAfterEnv 配置了 Jest setup 文件的地址,能够包含多个文件,这里设置的是项目根目录下的 src/setupJest.ts浏览器

第三步,在 src 目录下建立上一步中设置的 setup 文件 setupJest.tssession

import 'jest-preset-angular'; // jest 对于 angular 的预配置
import './jestGlobalMocks'; // jest 全局的 mock

第四步,在 src 目录下建立 jestGlobalMocks.ts 文件,并加入相关的全局的 mock,如下是一个例子:app

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.jsoncompilerOptions.type 的配置移除 jasmine, 加上 jest。

至此,你已经删除了全部与 Karma 相关的代码。你甚至还能将测试断言换成 jest 的风格。
查看最后生成的代码库和相关文件配置


参考:

相关文章
相关标签/搜索