本文共 6637 字，大约阅读时间需要 22 分钟。

近年来，随着前端工程化的发展，前端发生了翻天覆地的变化。jQuery已经慢慢淡出了我们的视野，React、Vue和anglur三驾马车急速驶来。从此，前端进入了数据驱动的时代，也有了清晰的模块化开发的方式。随之而来的就是如何去保证自己的代码的正确性。

为什么需要前端自动化测试

为什么我自己写的代码我还要去写测试代码去测试它？就这么不信任自己吗？答案：是的。永远不要相信自己写的代码，不然咋还会有那么多的bug。

除此之外，由于一个项目需要多人维护，也许别人不小心改动了你的代码就会导致新的问题。所以提交代码前需要跑一遍测试用例，确保自己没有改动别人的逻辑。如果有改动别人的代码，一定要弄清楚这样改动会不会产生新的问题，最后记得把测试用例代码也要改下。

前端测试工具一览

前端测试工具也和前端的框架一样纷繁复杂，其中常见的测试工具，大致可分为测试框架、断言库、测试覆盖率工具等几类。在正式开始本文之前，我们先来大致了解下它们：

测试框架

测试框架的作用是提供一些方便的语法来描述测试用例，以及对用例进行分组。

测试框架可分为两种： TDD （测试驱动开发）和 BDD （行为驱动开发），我理解两者间的区别主要是一些语法上的不同，其中 BDD 提供了提供了可读性更好的用例语法，至于详细的区别可参见  一文。

常见的测试框架有  ,  以及本文要介绍的  。

断言库

断言库主要提供语义化方法，用于对参与测试的值做各种各样的判断。这些语义化方法会返回测试的结果，要么成功、要么失败。常见的断言库有  ,  等。

测试覆盖率工具

用于统计测试用例对代码的测试情况，生成相应的报表，比如  。

Jest

为什么选择Jest？

Jest 是 Facebook 出品的一个测试框架，相对其他测试框架，其一大特点就是就是内置了常用的测试工具，比如自带断言、测试覆盖率工具，实现了开箱即用。

而作为一个面向前端的测试框架， Jest 可以利用其特有的  功能，通过比对 UI 代码生成的快照文件，实现对 React 等常见框架的自动测试。

此外， Jest 的测试用例是并行执行的，而且只执行发生改变的文件所对应的测试，提升了测试速度。目前在 Github 上其 star 数已经破两万；而除了 Facebook 外，业内其他公司也开始从其它测试框架转向 Jest ，比如  ，相信未来 Jest 的发展趋势仍会比较迅猛。

安装

Jest 可以通过 npm 或 yarn 进行安装。以 npm 为例，既可用 npm install -g jest 进行全局安装；也可以只局部安装、并在 package.json 中指定 test 脚本：

{  "scripts": {    "test": "jest"  }}

Jest 的测试脚本名形如 *.test.js ，不论 Jest 是全局运行还是通过 npm run test 运行，它都会 执行当前目录下所有的 *.test.js 或 *.spec.js 文件 、完成测试。

用法

具体用法参考  ，我们这里只是简单介绍几个常规用法。

用例的表示

表示测试用例是一个测试框架提供的最基本的 API ， Jest 内部使用了 Jasmine 2 来进行测试，故其用例语法与 Jasmine 相同。 test() 函数来描述一个测试用例，举个简单的例子：

// hello.jsmodule.exports = () => 'Hello world'

// hello.test.jslet hello = require('hello.js')test('should get "Hello world"', () => {    expect(hello()).toBe('Hello world') // 测试成功    // expect(hello()).toBe('Hello') // 测试失败})

其中 toBe('Hello world') 便是一句断言（ Jest 管它叫 “matcher” ，想了解更多 matcher 请参考  ）。写完了用例，运行在项目目录下执行 npm test ，即可看到测试结果。

用例的预处理或后处理

有时我们想在测试开始之前进行下环境的检查、或者在测试结束之后作一些清理操作，这就需要对用例进行预处理或后处理。对测试文件中所有的用例进行统一的预处理，可以使用 beforeAll() 函数；而如果想在每个用例开始前进行都预处理，则可使用 beforeEach() 函数。至于后处理，也有对应的 afterAll() 和 afterEach() 函数。

如果只是想对某几个用例进行同样的预处理或后处理，可以将先将这几个用例归为一组。 使用 describe() 函数即可表示一组用例 ，再将上面提到的四个处理函数置于 describe() 的处理回调内，就实现了对一组用例的预处理或后处理：

describe('test testObject', () => {    beforeAll(() => {        // 预处理操作    })    test('is foo', () => {       expect(testObject.foo).toBeTruthy()    })    test('is not bar', () => {        expect(testObject.bar).toBeFalsy()    })    afterAll(() => {        // 后处理操作    })})

测试异步代码

异步代码的测试，关键点在于 告知测试框架测试何时完成 ，让其在恰当的时机进行断言。随着Babel的盛行，前端的异步写法很多都是用 Promise 的形式了，这使得我们可以用 async/await 类似同步的方式写异步。下面看下如何针对这种写法测试：

// promiseHello.jsmodule.exports = (name) => {    return new Promise((resolve) => {        setTimeout(() => resolve(`Hello ${name}`), 1000)    })}

// promiseHello.test.jslet promiseHello = require('promiseHello.js')test('should get "Hello World"', async () => {  const data = await promiseHello('World');  expect(data).toBe('Hello World');});test('the fetch fails with an error', async () => {  expect.assertions(1);  try {    const data = await promiseHello('World');    expect(data).toBe('Hello World');  } catch (e) {    expect(e).toMatch('error');  }});

Mock Functions

Mock 函数允许你测试代码之间的连接——实现方式包括：擦除函数的实际实现、捕获对函数的调用 ( 以及在这些调用中传递的参数) 、在使用 new 实例化时捕获构造函数的实例、允许测试时配置返回值。

使用 mock 函数

假设我们要测试函数 forEach 的内部实现，这个函数为传入的数组中的每个元素调用一次回调函数。

function forEach(items, callback) {  for (let index = 0; index < items.length; index++) {    callback(items[index]);  }}

为了测试此函数，我们可以使用一个 mock 函数，然后检查 mock 函数的状态来确保回调函数如期调用。

const mockCallback = jest.fn(x => 42 + x);forEach([0, 1], mockCallback);// 此 mock 函数被调用了两次expect(mockCallback.mock.calls.length).toBe(2);// 第一次调用函数时的第一个参数是 0expect(mockCallback.mock.calls[0][0]).toBe(0);// 第二次调用函数时的第一个参数是 1expect(mockCallback.mock.calls[1][0]).toBe(1);// 第一次函数调用的返回值是 42expect(mockCallback.mock.results[0].value).toBe(42);

.mock 属性

所有的 mock 函数都有这个特殊的 .mock 属性，它保存了关于此函数如何被调用、调用时的返回值的信息。

// The function was called exactly onceexpect(someMockFunction.mock.calls.length).toBe(1);// The first arg of the first call to the function was 'first arg'expect(someMockFunction.mock.calls[0][0]).toBe('first arg');// The second arg of the first call to the function was 'second arg'expect(someMockFunction.mock.calls[0][1]).toBe('second arg');// The return value of the first call to the function was 'return value'expect(someMockFunction.mock.results[0].value).toBe('return value');// This function was instantiated exactly twiceexpect(someMockFunction.mock.instances.length).toBe(2);// The object returned by the first instantiation of this function// had a `name` property whose value was set to 'test'expect(someMockFunction.mock.instances[0].name).toEqual('test');

Mock 的返回值

Mock 函数也可以用于在测试期间将测试值注入代码︰

const myMock = jest.fn();console.log(myMock());// > undefinedmyMock  .mockReturnValueOnce(10)  .mockReturnValueOnce('x')  .mockReturnValue(true);console.log(myMock(), myMock(), myMock(), myMock());// > 10, 'x', true, true

在函数连续传递风格（functional continuation-passing style）的代码中时，Mock 函数也非常有效。 以这种代码风格有助于避免复杂的中间操作，便于直观表现组件的真实意图，这有利于在它们被调用之前，将值直接注入到测试中。

const filterTestFn = jest.fn();// Make the mock return `true` for the first call,// and `false` for the second callfilterTestFn.mockReturnValueOnce(true).mockReturnValueOnce(false);const result = [11, 12].filter(num => filterTestFn(num));console.log(result);// > [11]console.log(filterTestFn.mock.calls);// > [ [11], [12] ]

大多数现实世界例子中，实际是在依赖的组件上配一个模拟函数并配置它，但手法是相同的。 在这些情况下，尽量避免在非真正想要进行测试的任何函数内实现逻辑。

Mock模拟模块

假定有个从 API 获取用户的类。 该类用  调用 API 然后返回 data ，其中包含所有用户的属性：

// users.jsimport axios from 'axios';class Users {  static all() {    return axios.get('/users.json').then(resp => resp.data);  }}export default Users;

现在，为测试该方法而不调用实际 API (使测试变的缓慢与不稳定)，我们可以用 jest.mock(...) 函数自动模拟 axios 模块。

一旦模拟axios模块，axios的返回结果就可以被我们随意模拟值。我们可为 .get 提供一个 mockResolvedValue ，它会返回假数据用于测试。 实际上，我们想让 axios.get('/users.json') 有个假的 response。

// users.test.jsimport axios from 'axios';import Users from './users';jest.mock('axios');  // mock模拟模块test('should fetch users', () => {  const users = [{name: 'Bob'}];  const resp = {data: users};  axios.get.mockResolvedValue(resp);  // 模拟实际调用axios后的返回值  // or you could use the following depending on your use case:  // axios.get.mockImplementation(() => Promise.resolve(resp))  return Users.all().then(data => expect(data).toEqual(users));});

前端自动化测试的价值

近几年前端工程化的发展风起云涌，但是前端自动化测试这块内容大家却似乎不太重视。虽然项目迭代过程中会有专门的测试人员进行测试，但等他们来进行测试时，代码已经开发完成的状态。与之相比，如果我们在开发过程中就进行了测试，会有如下的好处：

• 保障代码质量和功能的实现的完整度
• 提升开发效率，在开发过程中进行测试能让我们提前发现 bug ，此时进行问题定位和修复的速度自然比开发完再被叫去修 bug 要快许多
• 便于项目维护，后续任何代码更新也必须跑通测试用例，即使进行重构或开发人员发生变化也能保障预期功能的实现

当然，凡事都有两面性，好处虽然明显，却并不是所有的项目都值得引入测试框架，毕竟维护测试用例也是需要成本的。对于一些需求频繁变更、复用性较低的内容，比如活动页面，让开发专门抽出人力来写测试用例确实得不偿失。

• 需要长期维护的项目。它们需要测试来保障代码可维护性、功能的稳定性

• 较为稳定的项目、或项目中较为稳定的部分。给它们写测试用例，维护成本低

• 被多次复用的部分，比如一些通用组件和库函数。因为多处复用，更要保障质量

参考：

转载地址：http://bvqni.baihongyu.com/