初尝 Jest 单元测试
最近的几次发布都犯了小错，都是缺乏或者忽视了测试所导致的。通常来说，一个新功能上线的时候，开发和测试都投入比较多，各项测试都是比较全面的。然而，发布上线也并非意味着不再有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的使用，有四两拨千斤效，不过重点在于其输入数据的构造。
可期。