初尝 Jest 单元测试

  • 2019 年 12 月 4 日
  • 筆記

最近的几次发布都犯了小错，都是缺乏或者忽视了测试所导致的。通常来说，一个新功能上线的时候，开发和测试都投入比较多，各项测试都是比较全面的。然而，发布上线也并非意味着不再有bug或者修改。那这时候问题来了，有些修改， 我们会以为很简单，从而放松警惕，偷懒也罢，没有精力也罢，简单验证之后便匆匆发布了。此时，有可能不经意的改动对其它功能造成了影响，bug复bug， bug何其多呀。

那web页面的发布，其优势是可以快速上线新功能或者bugfix，节奏很快，而其缺点也明显，相对于终端的版本发布需要重新走一遍比较重的测试流程而言，就没那么谨慎了。

那web也引入自动化测试吧

当然了，自动化测试不是说一句话那么简单了，前期选型框架，编写用例测试团队都不一定能支持得上，而且web功能变化如此频繁，更新用例说不定还真不如手工过一遍。

挑点简单可动手的， 开发同学自己写单元测试吧。

问题也就来了，做业务需求都没时间了，还要写测试用例？哪来的时间。。。

所以，写单元测试这件痛苦的事情，怎么办？

不同于几年前js乱七八糟，模块化都不普遍的时代，目前团队里主流技术栈就是React，以React天生强制组件化的思想来看，写单元测试应该是天时地利了，而Facebook也提供了配套的测试工具(ReactTestUtils)和测试框架(Jest)，所以，看怎么样在已有项目快速补充上单元测试吧。

Jest的口号是 Delightful JavaScript Testing，真的吗？

直奔相关主题，Jest 官网有一个tab Testing React Apps, 那对React是有特别照顾呀。

Snapshot Testing

所谓snapshot，即快照也。通常涉及UI的自动化测试，思路是把某一时刻的标准状态拍个快照，在测试回归的时候进行pixel to pixel的对比。但Jest对React组件的快照则不同，其实是把一个组件给序列化成纯文本， 纯文本的比较，这个真是简单又高效呀。对于一个React组件而言， 传入相同的props，我们是期望得到相同的输出， 这样子一来，通过构造不同的props, 我们即有了不同的测试用例。理想状态中，组件若是无内部状态变化，测试用例覆盖率应该可以达到100%了。当然，仅仅是理想。

先跑跑官网的简单例子，先照步骤安装npm依赖，然后敲代码，jest跑一下：

// Link.react.js  import React from 'react';    const STATUS = {    HOVERED: 'hovered',    NORMAL: 'normal',  };    export default class Link extends React.Component {      constructor(props) {      super(props);        this._onMouseEnter = this._onMouseEnter.bind(this);      this._onMouseLeave = this._onMouseLeave.bind(this);        this.state = {        class: STATUS.NORMAL,      };    }      _onMouseEnter() {      this.setState({class: STATUS.HOVERED});    }      _onMouseLeave() {      this.setState({class: STATUS.NORMAL});    }      render() {      return (        <a          className={this.state.class}          href={this.props.page || '#'}          onMouseEnter={this._onMouseEnter}          onMouseLeave={this._onMouseLeave}>          {this.props.children}        </a>      );    }
// Link.react-test.js  import React from 'react';  import Link from '../Link.react';  import renderer from 'react-test-renderer';    it('renders correctly', () => {    const tree = renderer.create(      <Link page="http://www.facebook.com">Facebook</Link>    ).toJSON();    expect(tree).toMatchSnapshot();  });

第一次跑的时候，就会生成一个快照文件，在__snapshots__目录下:

exports[`renders correctly 1`] = `  <a    className="normal"    href="http://www.facebook.com"    onMouseEnter={[Function]}    onMouseLeave={[Function]}  >    Facebook  </a>  `;

在之后的toMatchSnapshot()调用就会与之比较，如有不同，则是用例失败，会打印出具体差异：

如果是代码有修改，需要对应更新快速的话，则执行jest -u重新生成。

例子简单了， 怎么引入现有的项目呢？ 从其需要的依赖来看，

npm install --save-dev jest babel-jest babel-preset-es2015 babel-preset-react react-test-renderer

它是直接支持jsx语法和es6语法的，跑了一个最简单的组件，it works!

再跑一个，发现失败了，报找不到文件。观察下出错信息，发现是有一些文件引用是依赖构建工具处理的。比如说import util from assets/util jest运行的时候只在 node_modules 下去，当然找不到了。

机智的facebook团队早就想到了，Using with webpack 虽然项目用的是fis构建，但是思路是可以参考的，就是给jest加个解析路径的配置，在package.json中添加jest项配置，或者通过–config 参数指定配置文件：

"jest": {      "collectCoverage": true,      "testMatch": [ "**/__tests__/**/*.test.js?(x)"],      "moduleDirectories": ["node_modules", "src"], // 就是这个      "testPathIgnorePatterns": [        "/node_modules/",        "/dev",        "/src/server"      ]    }

在仅仅使用toMatchSnapshot()的情况下，

分支测试覆盖率达到80%以上了，而有一些代码还没有覆盖到，其实是因为组件内部有交互行为，比如说onClick，再继续下补充之后：

我们发现，整体覆盖率都大体提升，而实际上，仅仅就是加了20几行代码而已，就是处理onClick事件，图片的onError事件。

看起来，这样子添加测试用例，倒也不是很麻烦的样子，主要是snapshots的使用，有四两拨千斤效，不过重点在于其输入数据的构造。

可期。

VirMach 便宜 VPS

QNews

QNews