what
自动化测试类型
单元测试
测试一个独立的模块/函数能否正常工作
大多公共的工具库、组件由于需要被广泛引用，最好是需要单元测试的，相对应的，业务代码对单元测试的需求较少；单元测试的模块也往往是低耦合的模块
集成测试：
测试多个模块能否正常协同工作
测试粒度需要自己衡量抉择，基本流程与单测一致，只是测试范围更大更完整。
端到端测试（e2e）
从用户的角度，通过机器模仿与验证用户的交互体验
更像是传统产品中测试同学进行产品功能测试，从用户角度评价产品质量，对于e2e来说，你的项目代码是一个黑盒，它只关注你最后的功能是否满足需要，不在乎你的代码间的调度，甚至不在乎前后端之间的调度。
e2e测试能够覆盖一些ui测试，但是着重点还是不同的，因为e2e是在真实环境中进行测试的，和平常的开发流程不太一致，前后端分离式的话，对于前端来说，ui测试更需要。而e2e更多的是在联调时。
组件（UI）测试
纯前端的ui测试，脱离真实后端环境，后端数据都是mock的
组件测试：创建一个DOM节点，
快照测试：除了dom节点的测试，ui测试还包含快照测试：通过比较html结构或者图片快照与你需要的ui效果进行对比，判断是否一致。
其他测试工具
补充库：比如mocha不支持断言，可以用chai这类断言库补充功能。
测试代码覆盖率工具：istanbul，不过jest这种一般都自带这类工具
测试方式
- TDD（Test Drive Development）即测试驱动开发。简单的说就是先根据需求写测试用例，再代码实现，接着测试，循环此过程直到产品的实现。可以看出来，TDD 的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
- BDD（Behavior Drive Development）即行为驱动开发，BDD 可以看作是对 TDD 的一种补充，或者说是 TDD 的一个分支。在 TDD 中，我们并不能完全保证根据设计所编写的测试就是用户所期望的功能。BDD 将这一部分简单和自然化，用自然语言来描述，让开发、测试、BA 以及客户都能在这个基础上达成一致。BDD 更加依赖于需求行为和文档来驱动开发，这些文档的描述跟测试代码很相似。e2e 测试更多是和 BDD 的开发模式进行结合。
why
减少bug，减少人工检查，提高准确度，提高泛用性，防止边界条件没考虑充分。
减少自己打断点查bug，提高测试效率。
适合引入自动化测试的场景：
- 公共库类的开发维护
- 中长期项目的迭代/重构
- 引用了不可控的第三方依赖
感觉这个说的比较有道理，比如不会再迭代更新的项目没必要搞单测；公共包相对更需要自动化测试。
which
开源方案
2022.stateofjs.com/zh-Hans/是一个统计前端框架使用/满意程度等指标的排行榜，收集了一些开发者的调查结果，不能说和市场情况100%相符，不过2022年收集了将近四万份调查结果，还是比较有参考价值的。这个统计蛮有意思的，能看出一些前端框架的发展趋势。
比如这里以jest和mocha为例，能看出，jest大体发展势头还是比较好的，mocha基本已经处于一个被淘汰的边缘了。
- 看一下测试框架的使用统计：
这里是按满意度来进行的等级分配，满意度高不能完全代表好，毕竟可能受众相对较小，不过满意度高大概率是能说明未来发展势头应该是比较良好的。
认知率排名：
使用率排名：
个人认为，选择框架的时候主要考虑其成熟度(社区规模、发展时间等)、市场占有规模、和已有技术方案的适配程度，所以先不参考关注度和满意度（这两个指标更多体现的是未来发展的可能性，除非满意度大大降低，否则对目前的影响都是不太大的）
看认知率和使用率，jest这几年基本处于遥遥领先的地位，而且发展的时间也比较长。
总结一下不同框架：
- 功能总结：
- 能够基于一定配置在浏览器或是Node.js 中应用测试：Karma, Jasmine, Jest, TestCafe, Cypress, webdriverio
- 提供了测试框以帮助整个流程可读可扩展，目前通常基于BDD来构建测试用例：Mocha, Jasmine, Jest, Cucumber, TestCafe, Cypress
- 提供了断言的能力：Chai, Jasmine, Jest, Unexpected, TestCafe, Cypress
- 提供并展示测试结果：Mocha, Jasmine, Jest, Karma, TestCafe, Cypress
- 提供Mock能力即模拟函数、功能、场景并隔离能力：Mocha,Jasmine, Jest, Karma, TestCafe, Cypress
-
- 间谍函数：用于附加在监视的函数上面，并提供额外的信息，比如函数的调用次数，出入参。具体参照这里
- 存根函数：通过预编程的能力能够完全替代原函数，不会调用到原函数。具体参照这里
- 模拟函数：模拟模块及行为的能力，甚至于去虚构出服务器的响应。具体参照这里
- 提供并生成对比的快照能力，对比不同版本的内部数据结构，可以保证无论何时输出的UI都是理想情况下的：Jest, AVA
- 提供生成覆盖率报告单能力：IstanbulJS, Jest, Blanket
- 提供浏览器模拟控制的能力，比如模拟点击、拖动、敲击等动作：Nightwatch, Nightmare, Phantom , Puppeteer, TestCafe, Cypress
- 提供可视化回归工具，即对比网页的前后版本：Applitools, Percy, Wraith, WebdriverCSS
- 优缺点适用总结：
| 框架 | stateofjs rank | 适用类型 | 优点 | 缺点 |
|---|---|---|---|---|
| jest | 68% | 单元测试 | 集成断言等工具，开箱即用 | 社区健壮程度不如mocha，不太支持三方库 |
| storybook | 45% | UI测试工具（支持三大框架ui） | 完全适用于ui 组件开发管理的工具 | 靠人力更多，工程化比较差 |
| mocha | 44% | 单元测试 | 发展时间长，生态好（轻量、适用逻辑简单的项目） | 依赖nodejs/浏览器，不支持断言、模拟等，需要第三方插件，使用率逐年下降，不能开箱即用 |
| cypress | 42% | e2e | ||
| testing library | 35% | DOM测试（测试React组件）(本质上是一个库，搭配jest等使用) | React官方推荐，可以与jest协同使用，轻量，enzyme的同类产品 | |
| puppeteer | 34% | e2e（操作测试、性能测试 | ||
| selenium | 34% | e2e | 基于webdriver，浏览器兼容性更优 | |
| jasmine | 33% | 单元测试 | js单测框架，不依赖浏览器、js等；测试异步函数困难 | |
| playwright | 16% | e2e | ||
| vitest | 14% | 单元测试（vue原生测试） | ||
| webdriverio | 9% | e2e | ||
| ava | 6% | nodejs的测试工具 | 比较小众 | |
| testcafe | 4% | e2e | ||
| enzyme | - | 测试React组件 | 在jest的基础上，增加DOM操作的能力 | testing library作为同类产品好像对于react的集成更友好（官方推荐） |
| chai | - | 断言库，搭配使用 | 使用jest这种框架的话，没必要使用 |
- jest总体来说还是比较全面的测试框架，在jest的基础上加一个组件测试工具提高测试效果是比较好的。
- 如果直接使用storybook之类的进行ui/组件测试的话，自动化/工程性还是会差一些。
- jest、react testing library这两个是react官网提到的工具，可以优先考虑。legacy.reactjs.org/docs/testin…
ps: 这个内容在新版的react官网已经找不到了
- 参考：cloud.tencent.com/developer/a…，enzyme相比testing library的缺点
另外DOM测试和UI测试还是不太一样的，UI测试侧重于你的页面展示是否和期望一致，DOM测试更多的是去测试DOM节点是否正常渲染了（待补充）
