写在前面
关于前端单元测试，其实两年前我就已经关注了，但那时候只是简单的知道断言，想着也不是太难的东西，项目中也没有用到，然后就想当然的认为自己就会了。
两年后的今天，部门要对以往的项目补加单元测试。真到了开始着手的时候，却懵了 😂
我以为的我以为却把自己给坑了，我发现自己对于前端单元测试一无所知。然后我翻阅了大量的文档，发现基于dva的单元测试文档比较少，因此在有了一番实践之后，我梳理了几篇文章，希望对于想使用 Jest 进行 React + Dva + Antd 单元测试的你能有所帮助。文章内容力求深入浅出，浅显易懂～
介于内容全部收在一篇会太长，计划分为两篇，本篇是第一篇，主要介绍如何快速上手jest以及在实战中常用的功能及api
🏈 前端自动化测试产生的背景
在开始介绍jest之前，我想有必要简单阐述一下关于前端单元测试的一些基础信息。
为什么要进行测试？
在 2021 年的今天，构建一个复杂的web应用对于我们来说，并非什么难事。因为有足够多优秀的的前端框架（比如 React，Vue）；以及一些易用且强大的UI库（比如 Ant Design，Element UI）为我们保驾护航，极大地缩短了应用构建的周期。但是快速迭代的过程中却产生了大量的问题：代码质量（可读性差、可维护性低、可扩展性低）低，频繁的产品需求变动（代码变动影响范围不可控）等。
因此单元测试的概念在前端领域应运而生，通过编写单元测试可以确保得到预期的结果，提高代码的可读性，如果依赖的组件有修改，受影响的组件也能在测试中及时发现错误。
测试类型又有哪些呢？
一般常见的有以下四种：
单元测试
功能测试
集成测试
冒烟测试
常见的开发模式呢？
TDD: 测试驱动开发
BDD: 行为驱动测试
🎮 技术方案
针对项目本身使用的是React + Dva + Antd的技术栈，单元测试我们用的是Jest + Enzyme结合的方式。
Jest
关于Jest，我们参考一下其Jest 官网，它是Facebook开源的一个前端测试框架，主要用于React和React Native的单元测试，已被集成在create-react-app中。Jest特点：
零配置
快照
隔离
优秀的 api
快速且安全
代码覆盖率
轻松模拟
优秀的报错信息
Enzyme
Enzyme是Airbnb开源的React测试工具库，提供了一套简洁强大的API，并内置Cheerio，同时实现了jQuery风格的方式进行DOM处理，开发体验十分友好。在开源社区有超高人气，同时也获得了React官方的推荐。
* Jest
本篇文章我们着重来介绍一下Jest，也是我们整个React单元测试的根基。
环境搭建
安装
安装Jest、Enzyme。如果React的版本是15或者16，需要安装对应的enzyme-adapter-react-15和enzyme-adapter-react-16并配置。
jest.config.js
可以运行npx jest --init在根目录生成配置文件jest.config.js
这里只是列举了常用的配置项：
automock: 告诉 Jest 所有的模块都自动从 mock 导入.
clearMocks: 在每个测试前自动清理 mock 的调用和实例 instance
collectCoverage: 是否收集测试时的覆盖率信息
collectCoverageFrom: 生成测试覆盖报告时检测的覆盖文件
coverageDirectory: Jest 输出覆盖信息文件的目录
coveragePathIgnorePatterns: 排除出 coverage 的文件列表
coverageReporters: 列出包含 reporter 名字的列表，而 Jest 会用他们来生成覆盖报告
coverageThreshold: 测试可以允许通过的阈值
moduleDirectories: 模块搜索路径
moduleFileExtensions：代表支持加载的文件名
testPathIgnorePatterns：用正则来匹配不用测试的文件
setupFilesAfterEnv：配置文件，在运行测试案例代码之前，Jest 会先运行这里的配置文件来初始化指定的测试环境
testMatch: 定义被测试的文件
transformIgnorePatterns: 设置哪些文件不需要转译
transform: 设置哪些文件中的代码是需要被相应的转译器转换成 Jest 能识别的代码，Jest 默认是能识别 JS 代码的，其他语言，例如 Typescript、CSS 等都需要被转译。
匹配器
toBe(value)：使用 Object.is 来进行比较，如果进行浮点数的比较，要使用 toBeCloseTo
not：取反
toEqual(value)：用于对象的深比较
toContain(item)：用来判断 item 是否在一个数组中，也可以用于字符串的判断
toBeNull(value)：只匹配 null
toBeUndefined(value)：只匹配 undefined
toBeDefined(value)：与 toBeUndefined 相反
toBeTruthy(value)：匹配任何语句为真的值
toBeFalsy(value)：匹配任何语句为假的值
toBeGreaterThan(number)： 大于
toBeGreaterThanOrEqual(number)：大于等于
toBeLessThan(number)：小于
toBeLessThanOrEqual(number)：小于等于
toBeInstanceOf(class)：判断是不是 class 的实例
resolves：用来取出 promise 为 fulfilled 时包裹的值，支持链式调用
rejects：用来取出 promise 为 rejected 时包裹的值，支持链式调用
toHaveBeenCalled()：用来判断 mock function 是否被调用过
toHaveBeenCalledTimes(number)：用来判断 mock function 被调用的次数
assertions(number)：验证在一个测试用例中有 number 个断言被调用
命令行工具的使用
在项目package.json文件添加如下script:
此时运行npm run test:
我们发现有以下几种模式：
f: 只会测试之前没有通过的测试用例
o: 只会测试关联的并且改变的文件（需要使用 git）（jest --watch 可以直接进入该模式）
p: 测试文件名包含输入的名称的测试用例
t: 测试用例的名称包含输入的名称的测试用例
a: 运行全部测试用例
在测试过程中，你可以切换适合的模式。
钩子函数
类似于 react 或者 vue 的生命周期，一共有四种：
beforeAll()：所有测试用例执行之前执行的方法
afterAll()：所有测试用例跑完以后执行的方法
beforeEach()：在每个测试用例执行之前需要执行的方法
afterEach()：在每个测试用例执行完后执行的方法
这里，我以项目中的一个基础 demo 来演示一下具体使用：
Counter.js
Counter.test.js
运行npm run test:
通过第一个测试用例加 1，number的值为 1，当第二个用例减 1 的时候，结果应该是 0。但是这样两个用例间相互干扰不好，可以通过 Jest 的钩子函数来解决。修改测试用例：
运行npm run test:
可以清晰的看到对应钩子的执行顺序：
beforeAll > (beforeEach > afterEach)(单个用例都会依次执行) > afterAll 除了以上这些基础知识外，其实还有异步代码的测试、Mock、Snapshot 快照测试等，这些我们会在下面 React 的单元测试示例中依次讲解。
异步代码的测试
众所周知，JS中充满了异步代码。
正常情况下测试代码是同步执行的，但当我们要测的代码是异步的时候，就会有问题了：test case实际已经结束了，然而我们的异步代码还没有执行，从而导致异步代码没有被测到。
那怎么办呢？
对于当前测试代码来说，异步代码什么时候执行它并不知道，因此解决方法很简单。当有异步代码的时候，测试代码跑完同步代码后不立即结束，而是等结束的通知，当异步代码执行完后再告诉jest：“好了，异步代码执行完了，你可以结束任务了”。
jest提供了三种方案来测试异步代码，下面我们分别来看一下。
done 关键字
当我们的test函数中出现了异步回调函数时，可以给test函数传入一个done参数，它是一个函数类型的参数。如果test函数传入了done，jest就会等到done被调用才会结束当前的test case，如果done没有被调用，则该test自动不通过测试。
上面的代码中，我们给test函数传入了done参数，在fetchData的回调函数中调用了done。这样，fetchData的回调中异步执行的测试代码就能够被执行。
但这里我们思考一种场景：如果使用done来测试回调函数（包含定时器场景，如setTimeout），由于定时器我们设置了 一定的延时（如 3s）后执行，等待 3s 后会发现测试通过了。那假如 setTimeout 设置为几百秒，难道我们也要在 Jest 中等几百秒后再测试吗？
显然这对于测试的效率是大打折扣的！！
jest中提供了诸如jest.useFakeTimers()、jest.runAllTimers()和toHaveBeenCalledTimes、jest.advanceTimersByTime等api来处理这种场景。
这里我也不举例详细说明了，有这方面需求的同学可以参考Timer Mocks
返回 Promise
⚠️ 当对Promise进行测试时，一定要在断言之前加一个return，不然没有等到Promise的返回，测试函数就会结束。可以使用.promises/.rejects对返回的值进行获取，或者使用then/catch方法进行判断。
如果代码中使用了Promise，则可以通过返回Promise来处理异步代码，jest会等该promise的状态转为resolve时才会结束，如果promise被reject了，则该测试用例不通过。
注意，上面的第二个测试用例可用于测试promise返回reject的情况。这里用.catch来捕获promise返回的reject，当promise返回reject时，才会执行expect语句。而这里的expect.assertions(1)用于确保该测试用例中有一个expect被执行了。
对于Promise的情况，jest还提供了一对匹配符resolves/rejects，其实只是上面写法的语法糖。上面的代码用匹配符可以改写为：
async/await
我们知道async/await其实是Promise的语法糖，可以更优雅地写异步代码，jest中也支持这种语法。
我们把上面的代码改写一下：
⚠️ 使用async不用进行return返回，并且要使用try/catch来对异常进行捕获。
Mock
介绍jest中的mock之前，我们先来思考一个问题：为什么要使用mock函数？
在项目中，一个模块的方法内常常会去调用另外一个模块的方法。在单元测试中，我们可能并不需要关心内部调用的方法的执行过程和结果，只想知道它是否被正确调用即可，甚至会指定该函数的返回值。这个时候，mock的意义就很大了。
jest中与mock相关的api主要有三个，分别是jest.fn()、jest.mock()、jest.spyOn()。使用它们创建mock函数能够帮助我们更好的测试项目中一些逻辑较复杂的代码。我们在测试中也主要是用到了mock函数提供的以下三种特性：
捕获函数调用情况
设置函数返回值
改变函数的内部实现
下面，我将分别介绍这三种方法以及他们在实际测试中的应用。
jest.fn()
jest.fn()是创建mock函数最简单的方式，如果没有定义函数内部的实现，jest.fn()会返回undefined作为返回值。
jest.fn()所创建的mock函数还可以设置返回值，定义内部实现或返回Promise对象。
jest.mock()
一般在真实的项目里，测试异步函数的时候，不会真正的发送 ajax 请求去请求这个接口，为什么？
比如有 1w 个接口要测试，每个接口要 3s 才能返回，测试全部接口需要 30000s，那么这个自动化测试的时间就太慢了
我们作为前端只需要去确认这个异步请求发送成功就好了，至于后端接口返回什么内容我们就不测了，这是后端自动化测试要做的事情。
这里以一个axios请求的demo为例来说明：
对应测试文件user.test.js:
我们在测试用例的最上面加入了jest.mock('axios')，我们让jest去对axios做模拟，这样就不会去请求真正的数据了。然后调用axios.get的时候，不会真实的请求这个接口，而是会以我们写的{ data: ['Cosen','森林','柯森'] }去模拟请求成功后的结果。
当然模拟异步请求是需要时间的，如果请求多的话时间就很长，这时候可以在本地mock数据，在根目录下新建 __mocks__文件夹。这种方式就不用去模拟axios，而是直接走的本地的模拟方法，也是比较常用的一种方式，这里就不展开说明了。
jest.spyOn()
jest.spyOn()方法同样创建一个mock函数，但是该mock函数不仅能够捕获函数的调用情况，还可以正常的执行被spy的函数。实际上，jest.spyOn()是jest.fn()的语法糖，它创建了一个和被spy的函数具有相同内部代码的mock函数。
Snapshot 快照测试
所谓snapshot，即快照也。通常涉及 UI 的自动化测试，思路是把某一时刻的标准状态拍个快照。
当使用toMatchSnapshot的时候，Jest 将会渲染组件并创建其快照文件。这个快照文件包含渲染后组件的整个结构，并且应该与测试文件本身一起提交到代码库。当我们再次运行快照测试时，Jest 会将新的快照与旧的快照进行比较，如果两者不一致，测试就会失败，从而帮助我们确保用户界面不会发生意外改变。
🎯 总结
到这里，关于前端单元测试的一些基础背景和Jest的基础api就介绍完了，在下一篇文章中，我会结合项目中的一个React组件来讲解如何做组件单元测试。
作者：前端森林 来源：掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
