作者 | kinkahuang
链接 | http://imweb.io/topic/592aab6eff03ef1a4ef15c51
最近的几次发布都犯了小错，都是缺乏或者忽视了测试所导致的。通常来说，一个新功能上线的时候，开发和测试都投入比较多，各项测试都是比较全面的。然而，发布上线也并非意味着不再有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跑一下：
第一次跑的时候，就会生成一个快照文件，在__snapshots__目录下:
在之后的toMatchSnapshot()调用就会与之比较，如有不同，则是用例失败，会打印出具体差异：
如果是代码有修改，需要对应更新快速的话，则执行jest -u重新生成。
例子简单了， 怎么引入现有的项目呢？ 从其需要的依赖来看，
它是直接支持jsx语法和es6语法的，跑了一个最简单的组件，it works!
再跑一个，发现失败了，报找不到文件。观察下出错信息，发现是有一些文件引用是依赖构建工具处理的。比如说import util from assets/util jest运行的时候只在 node_modules 下去，当然找不到了。
机智的facebook团队早就想到了，Using with webpack 虽然项目用的是fis构建，但是思路是可以参考的，就是给jest加个解析路径的配置，在package.json中添加jest项配置，或者通过--config 参数指定配置文件：
在仅仅使用toMatchSnapshot()的情况下，分支测试覆盖率达到80%以上了，而有一些代码还没有覆盖到，其实是因为组件内部有交互行为，比如说onClick：
再继续下补充之后：
我们发现，整体覆盖率都大体提升，而实际上，仅仅就是加了20几行代码而已，就是处理onClick事件，图片的onError事件。
看起来，这样子添加测试用例，倒也不是很麻烦的样子，主要是snapshots的使用，有四两拨千斤效，不过重点在于其输入数据的构造。
扫码下方二维码，
随时关注更多前端干货文章！
▼
微信：IMWebTech
