Jest + Enzyme React 组件测试实践

≈
最近把组件测试接入到日常开发，提高了项目代码健壮性，可维护性。本人也从0到1收获了组件测试的经验。

本文总结一下最近两周 组件测试 相关的研究，包括：

• Jest + Enzyme 的基本介绍
• Jest + Enzyme 的实践
• Jest 原理浅析
• Jest 生态 & 未来

为什么选择Jest & Enzyme？

1. Jest

Jest 是一套Facebook家背书的测试框架。

实际上，编写一个测试用例，我们需要以下准备：

1. 一个测试类库
2. 一个断言库（assertion）
3. 一个测试执行环境（environment）
4. 其他（function or module mock, snapshot etc…）

Jest是包含以上（1234）四合一的一款测试框架。

• Jest内置了jsDOM和Node的执行环境。默认开启面向浏览器端的jsDOM环境。
• Jest内置一套断言库，和Jasmine相同语法。
• Jest自带函数和模块的Mock能力；自己发明了一个专门针对组件测试的快照（snapshot）测试；Jest支持热更新；Jest支持多线程测试。

当然Jest也有一些劣势。

2019年另一款很火的测试框架Mocha，自身不带断言库，也不带Func/Module Mock，集成社区相对成熟的断言库Chai和mock库SinonJS之后，非常强大。Chai断言库相较于Jest内置的断言库API更加丰富更加强大，SinonJS的mock的API也十分完善。而且Mocha的不带其他杂七杂八功能的理念，让它十分具有可配置性。

但是最终选择Jest原因有以下几点：

1. 没有最牛逼的框架，只有最合适的框架。

• 对于组件库的项目，我们对于组件测试的需求非常大，包括组件API的测试和组件呈现效果的测试。Jest自带的snapshot的测试，很亮眼，会把组件渲染的DOM解析成JSON作为快照保存，下一次再获得新的DOM的JSON序列，与旧的序列进行对比，保证组件的呈现的稳定性。
• 组件库的测试很少涉及到网络请求，server端测试，目前是一个纯浏览器端的测试需求。所以Jest自带的断言能力，mock能力够用。而且据我所知，Jest是有一个叫做jest-extend的断言库扩展包。甚至，自己手写就好了。

2. 更简单的配置，更快地上手。

• 实现一个snapshot，只需一句话：expect(component).toMatchSnapshot()，很简单。
• 断言库来自Jasmine，很精炼，够用，简单。

3. 实际上Jest的可配置化也非常强。

• Jest有自己的生态建设（Jest Community）。目前可以配置更加强大的断言扩展，更加灵活的运行环境，甚至还有snapshot使用svg保存的拓展（实际上Jest有倾向做真正的视觉测试，像素比较？？？好酷鸭）
• Jest自身的配置文件可配置项非常多。我就通过Jest的config配置文件把一个storybook文章生成文件mock成测试用例了哈哈（理论上讲，任何文件都可以变成测试文件）。

4. MVVM框架支持度

• 目前Jest支持市