前端测试的类型细分众多，测试技术选型更是五花八门，甚至容易弄混，下面来简单了解一下吧
测试分类
前端测试大致可以如下几类
- 静态测试: 在编写代码逻辑阶段时进行报错提示。(代表库: eslint、TypeScript)
- 单元测试：对软件中最小可测试单元进行检查和验证，通常指的是独立测试单个函数，职责是对一些边界情况或者特定的算法进行测试
- UI 测试：对图形交互界面的测试
- 端到端测试：站在用户的角度，把程序看成黑盒，只负责打开浏览器，把测试内容在页面上输入一遍，看是不是我想要的结构
技术选型
技术选型五花八门，为方便了解到最合适的方案，直接使用 vue-cli 和 cra 看看 Vue 和 React 脚手架的技术选型是什么
- vue-cli：jest + @vue/test-utils + cypress
- cra：jest + @testing-library/react
- umi：jest + enzyme + puppeteer
从上可以看出 cra 并没有提到端到端测试，但 umi（阿里一个团队推出的）中使用 puppeteer，且该团队使用的 UI 测试框架是 enzyme，但作者自己也说 @testing-library/react 将成为主流，enzyme 淡出，因此这里我们只简单了解一下 enzyme 和 @testing-library/react 的区别，驻点学习后者。
值得一提的是 jest 基于 Jasmine，做了大量修改并添加了很多特性。
enzyme vs @testing-library/react
- enzyme 出来更早，但常常滞后于 React 功能的实现，后者出现比较晚，倾向与支持 React 新特性
- enzyme 从代码实现的角度出现进行测试，基于 props 和 state
- React Testing Library 从用户体验的角度出发，基于 dom 进行测试，拥有更好的开发体验和更稳定的测试
enzyme 安装依赖
npm install --save-dev enzyme enzyme-adapter-16
react-testing-library 依赖安装
npm install --save-dev @testing-library/jest-dom @testing-library/react
再来看看 Puppeteer， 是 Google Chrome 团队推出的库，尽管它相对其他 e2e 框架更新，但它同样也有一个庞大的社区。它拥有更简洁易用的 API，更快的运行速度，已逐渐成为业内自动化测试的标杆，俘获大量 Selenium 用户的心。
因此针对 React 项目开发，推荐技术选型为：Jest + React Testing Library + Puppeteer
原则与优先级
编写原则
- 对测试代码，只考虑测试，不考虑实现
- 数据尽量模拟现实，越接近现实越好
- 充分考虑数据的边界条件
- 对重点、复杂核心代码，重点测试
- 利用 AOP（beforeEach，afterEach），减少测试代码数量
对于单元测试来说，是成本低且收益高，而对 UI 测试来说，可能更像是成本高但收益低。但是对于一些公共组件的测试还是很有必要的，当项目的代码足够复杂时，一个通用组件的改动迎接你的可能就是一个线上 Case。
对于 e2e 测试而言，通常我们不需要写太多，毕竟我们有专业的 QA 同学，大致覆盖一些简单的主流程即可。
只有单元测试和 UI 测试会计算到测试覆盖率，而 e2e 不会被计算进去。e2e 不需要写太多，因为大部分关键逻辑已经被单元测试覆盖，e2e 只需要简单的进行主流程的模拟。
同时由于目前项目大多属于敏捷开发，UI 样式的改动或者功能性需求较多，时间上也无法允许我们做到更好的测试覆盖。因此大概优先级
- 通用组件、工具类函数
- 业务逻辑
- 业务组件
- e2e 测试
编写测试简单规则，又叫做 AAA 模式
- 编排（Arrange）：初始化代码，为接下来步骤做准备
- 渲染组件：render
- 获取所需 DOM 的不同元素，getXXX
- 执行（Act）：执行用户应该执行的步骤，比如点击
- fireEvent
- 断言（Assert）：对应该发生的事情进行断言
- expect
聚焦和忽略用例：使用 xit() 取代 it() 可以暂时忽略用例，fit() 可以聚焦当前用例并忽略其他所有用例。这两个方法可以帮助你在开发过程中只关注当前需要的用例。
具体使用
简单使用可以直接参考：CRA Running Tests
里面有典型例子可以参考： 用Jest来给React完成一次妙不可言的~单元测试