测试类型
- 单元测试：指的是以原件的单元为单位，对软件进行测试。单元可以是一个函数，也可以是一个模块或一个组件，基本特征就是只要输入不变，必定返回同样的输出。一个软件越容易些单元测试，就表明它的模块化结构越好，给模块之间的耦合越弱。React的组件化和函数式编程，天生适合进行单元测试
- 功能测试：相当于是黑盒测试，测试者不了解程序的内部情况，不需要具备编程语言的专门知识，只知道程序的输入、输出和功能，从用户的角度针对软件界面、功能和外部结构进行测试，不考虑内部的逻辑
- 集成测试：在单元测试的基础上，将所有模块按照设计要求组装成子系统或者系统，进行测试
- 冒烟测试：在正式全面的测试之前，对主要功能进行的与测试，确认主要功能是否满足需要，软件是否能正常运行
前端需要自动化测试吗？
成本较大，对需求改动较小的比较适合
前端自动化认为应该有限量的做。
如果项目还在需求频繁变更，界面 UI 还不稳定，还在尝试不同的调整，而且调整都是比较大的，对前端做自动化收益小于成本
如果项目已经比较稳定，或者本来就是一个比较稳定的界面，比如工具类的 APP，UI 一般都是小调整，变更不会频繁，这种时候可以比较大量的做前端的自动化
不过无论什么时候，都应该是大量的做单元测试，大量的做 API 自动化测试，根据具体项目情况，少量或中等强度的做前端自动化
像antd， vue， react这种大型项目，都是有他对应的自动化测试代码的。
可以解决什么问题？
修水管修这处，坏那处的情况。长时间不动代码，或者接手其他人代码，或者出现重大修改的时候。
删除不必要的函数和代码块
至少要对主要流程做自动化，一来可以降低改 bug 制造新的 bug 的概率，二来对重大改动方便回归测试，不然手动测试工作量大，风险也大。
自动化测试的重点不是实现自动化测试或者把它加入到开发上线流程中，而是要对用例做收集管理，借助丰富的用例来保证代码质量。
而用例的收集管理是否可以成功，取决于业务是否稳定可预测。
现阶段国内的IT行业还处于高速增长期，业务善变不稳定。尤其是UI的变化更是频繁。此时收集管理用例成了西西弗斯的惩罚，消耗人力不说，还无法用来保证代码质量。
对于与业务无关的底层框架、库来说，自动化测试一直是存在的。但正如他们所处的位置，相对公司范围，只会是小范围小团队对其它有依赖，难以扩大影响，在频繁变更的业务线也无法推广。
Jest
Jest：目前最流行的前端测试框架，几乎国内所有的大型互联网公司都在使用。
npm install jest@24.8.0 -D
一.初步认识
两个方法：
- test方法：Jest封装的测试方法，一般填写两个参数，描述和测试方法
- expect方法 ：预期方法，就是你调用了什么方法，传递了什么参数，得到的预期是什么(代码中详细讲解)。
demo1：ktvsing.js
1.写一个测试对象，比如一个函数
2.写出测试用例
3.测试，查看结果
二.初始化Jest配置
npx jest --init 生成 jest.config.js文件
coverageDirectory : "coverage" //打开测试覆盖率选项
npx jest --coverage 生成代码覆盖率的文件
npx和npm的区别： npx后面接直接的命令，相当于npm接scripts中的key。
三.Jest中的匹配器
四.测试异步代码
1.回调函数式
2.直接返回promise
3.使用async await
五.四个钩子函数
六.Jest对测试用例的分组
七.钩子函数的作用域
八.代码覆盖率
行覆盖率(line coverage)：是否测试用例的每一行都执行了
函数覆盖率(function coverage)：测试是否用例的每一个函数都调用了
分支覆盖率(branch coverage)：测试用例的每个if代码块是否都执行了
语句覆盖率(statement coverage)：是否测试用例的每个语句都执行了
