React总结篇之八_单元测试

一、单元测试的原则
从不同的角度，可以将测试划分为如下不同的种类：

• 从人工操作还是写代码来操作的角度，可以分为手工测试和自动化测试；
• 从是否需要考虑系统的内部设计角度，可以分为白盒测试和黑盒测试；
• 从测试对象的级别，可以分为单元测试、集成测试和端到端测试；
• 从测试验证的系统特性，又可以分为功能测试、性能测试和压力测试。

单元测试是一种自动化测试，测试代码和被测的对象非常相关，比如测试React组件的代码就和测试jQuery的插件的代码完全不是一回事。
单元测试代码一般都由编写对应功能代码的开发者来编写，开发者提交的单元测试代码应该保持一定的覆盖率，而且必须永远能够运行通过。可以说，单元测试是保证代码质量的第一道防线。

开发者应该注意：
首先，即使单元测试覆盖率达到100%，也不表示程序是没有bug的；
另外，程序架构的可测试性非常重要，需要架构能把程序拆分成足够小到方便测试的部分，只要每个小的部分被验证能够正确的各司其职，组合起来能够完成整体功能，那么开发者编写的单元测试就可以专注于测试各个小的部分就行，这就是更高的可测试性。

二、单元测试环境搭建

• 单元测试框架
• 单元测试代码组织
• 辅助工具

1. 单元测试框架
   常见的是以下两种：
   • 用Mocha测试框架，但是Mocha并没有断言库，所以往往还要配合Chai断言库来使用，也就是Mocha+Chai的组合。
   • 使用React的本家Facebook出品的Jest，Jest自带了断言等功能，相当于包含了Mocha和Chai的功能，不过Jest和Chai并不一致。

create-react-app创建的应用中自带了Jest库，Jest会自动在当前目录下寻找满足下列任一条件的JavaScript文件作为单元测试代码来执行：

• 文件名以.test.js为后缀的代码文件；
• 存于test目录下的代码文件

2. 单元测试代码组织
   单元测试代码的最小单位是测试用例，每一个测试用例考验的是被测试对象在某一特定场景下是否有正确的行为。在Jest框架下，每个测试用例用一个it函数代表，it函数的第一个参数是一个字符串，代表的是测试用例名称，第二个参数是一个函数，包含的就是实际的测试用例的过程。一个很简单的单元测试用例代码如下：
   it(’should return object when invoked',()=>{
   //增加断言语句
   });

组织多个it函数实例，即测试套件。
在Jest中用describe函数描述测试套件，一个测试套件的代码如下：
describe('actions'，()=>{
it('should return object when invoked',()=>{});
//可以有更多的it函数调用
})

describe函数包含与it函数一样的参数，两者主要的区别就是describe可以包含it或者另一个describe函数调用，但是it却不能。
describe中有如下特殊函数可以帮助重用代码：

• beforeAll：在开始测试套件之前执行一次；
• afterAll：在结束测试套件中所有测试用例之后执行一次；
• beforeEach：每个测试用例在执行之前都执行一次；
• afterEach：每个测试用例在执行之后都执行一次

3. 辅助工具