什么是前端测试
我们经常说的单元测试其实只是前端测试的一种。前端测试分为单元测试，UI 测试，集成测试和端到端测试。
● 单元测试：是指对软件中的最小可测试单元进行检查和验证，通常指的是独立测试单个函数。
● UI 测试：是对图形交互界面的测试。
● 集成测试：就是测试应用中不同模块如何集成，如何一起工作，这和它的名字一致。
● 端到端测试（e2e）：是站在用户角度的测试，把我们的程序看成是一个黑盒子，我不懂你内部是怎么实现的，我只负责打开浏览器，把测试内容在页面上输入一遍，看是不是我想要得到的结果。
为什么要做自动化测试
● 产品周期较长，需要不断进行迭代/重构的项目
● 测试人力不足，回归测试耗时耗力
● 验证代码正确性，保障产品质量
● 提高测试效率
● 起到文档作用
适合引入自动化测试的场景
- 公共库类的开发维护
- 中长期项目的迭代/重构
- 引用了不可控的第三方依赖
测试有两种模式
● BDD（Behavior-driven development）：行为驱动开发，先实现功能后写测试。
● TDD（Test-driven development）：测试驱动开发，先写测试后实现功能
● 我们在开发业务系统的时候难免要自己封装一些 hook、组件、工具函数，那么我们可以使用 TDD 来做（借助 Vitest 或者 Cypress 的单元测试功能），开发业务代码的时候使用 BDD 来做（借助 Cypress 的 E2E 测试功能 ）
前端测试的框架有什么?
前端实现自动化测试页面的关键是选择合适的自动化测试框架和工具。以下是一些常用的工具和框架：
- 单元测试（Unit Test）有 Mocha, Ava, Karma, Jest, Jasmine, Vitest 等。
- 集成测试（Integration Test）和 UI 测试（UI Test）有 ReactTestUtils, Test Render, Enzyme, React-Testing-Library, Vue-Test-Utils 等。
- E2E 测试框架主要包括 Puppeteer、Cypress、Playwright(微软出品,配合vscode插件使用)、Selenium 、cucumber、TestCafe、python等。
- 它们之间各有优劣，适用场景也有所不同，我们会在下面进行比较。
- 与其他测试场景的重要不同之一，就是 E2E 测试是可以由测试同学来编写的（如支持 Python 和 Java 的 Selenium），在产品进行迭代的同时，测试同学会按照功能点变化对应地完善测试用例，同时确保以往所有功能的测试用例不受影响。
- 结论：非常简单的场景使用 Puppeteer（需要搭配 Jest-Puppeteer），PC 应用使用 Cypress, Playwright，移动端应用使用 Playwright。
- 它们之间各有优劣，适用场景也有所不同，我们会在下面进行比较。
- 压力测试
- 后端服务特殊的测试场景则是压力测试，在某些时候也可以被等价于性能测试，从某些方面它其实也是在模拟用户，只不过不是模拟一个用户的交互行为，而是模拟较大量级的用户访问，以此来测试服务的性能。本质上压力测试并不是在测试 API 的逻辑，而是承载 API 的服务器性能与负载均衡相关逻辑。进行压力测试可以很简单地使用脚本开多线程并发请求，也可以使用 Apache Bench、Webbench、wrk（wrk2）测试工具，或者 npm 社区也有 autocannon 这样的实现
针对具体的需求和项目特点，可以选择相应的自动化测试框架和工具，然后可以根据测试用例和测试需求，设计和实现自动化测试页面。常用的实现方式包括模拟用户操作、模拟网络请求、模拟响应等。
前端自动化测试工具优势劣势对比
| 框架名称 | 支持测试类型 | 可视化测试 | 自带断言库 | 开箱即用 | 录制生成脚本 | 优势 | 劣势 |
|---|---|---|---|---|---|---|---|
| Selenium | Web UI | 否 | 否 | 否 | 是 | 支持多种语言，支持跨平台，使用广泛 | 速度较慢，需要手动处理浏览器驱动的下载和管理 |
| Cypress | Web UI | 是 | 是 | 是 | 否 | 速度快，自带断言库，可视化测试，支持动态测试数据，可适用于测试和开发环境 | 不支持多浏览器测试，只能运行在 Chromium 内核浏览器上 |
| Puppeteer | Web UI | 否 | 否 | 否 | 是 | 支持跨平台，提供了高级 API 可以控制浏览器的行为，使用方便 | 不能运行在非 Chrome 浏览器上，需要手动处理浏览器驱动的下载和管理 |
| Playwright | Web UI | 是 | 否 | 是 | 否 | 支持多种语言，可视化测试，支持多浏览器测试，速度快 | 没有 Selenium 和 Cypress 那么成熟和稳定，生态相对较小 |
| Cucumber | BDD | 否 | 否 | 否 | 否 | 支持 BDD 测试，易于阅读和理解，可用于业务人员和开发人员之间的交流 | 需要手动编写步骤定义和步骤实现，使用过程较为繁琐 |
| TestCafe | Web UI | 否 | 是 | 是 | 否 | 可以运行在多个浏览器上，速度快，自带断言库，不需要编写显式等待 | 对特殊网站的支持较差，文档相对较少 |
| Python | Web UI/API | 否 | 是 | 是 | 是 | 用 Python 写测试代码，可用于 Web UI 和 API 测试 | 对于不熟悉 Python 的前端工程师来说使用难度较大 |
| React-Testing-Library | React 组件测试 | 否 | 是 | 是 | 否 | 专注于测试 React 组件，易于使用和理解，支持 Jest 和其他测试框架 | 不支持非 React 项目的测试 |
| Jest | Web UI/API | 否 | 是 | 是 | 否 | 自带断言库，支持异步测试，能够模拟浏览器环境，对 React 和 Vue 有较好的支持 | 对特殊网站的支持较差，部分 API 变动不够友好 |
| Vitest | Web UI | 否 | 否 | 是 | 否 | 可以运行在多个浏览器上，支持多种测试类型，使用 Jasmine 作为断言库 | 生态相对较小，文档相对较少 |
注：Web UI 表示 Web 界面测试，API 表示接口测试，BDD 表示行为驱动开发，React 组件测试表示专门针对 React 组件的测试。
选择第三方 NPM 包标准
● 检查开源许可证
● 看贡献频率和下载量
● 权衡包体积大小
● 是否有大型开发团队在进行维护
● 评估安全性
背景-项目架构 (业务不同,跳过)
○ ice + tech ui + react , mpa多页应用
■ ice官方推荐:
● jest and vitest , ui测试 和 非ui测试
● 组件 UI 测试推荐使用 @testing-library/react 和 @testing-library/jest-dom
最终的测试方案 (根据项目环境自行制定)
- 最终的测试方案
- Jest + Playwright
- Jest：一个基于JavaScript的测试框架，用于测试React应用程序。它可以进行单元测试、集成测试和端到端测试，并且提供了许多有用的测试工具和断言库。
- Playwright：开箱即用, 支持录制，脚本清晰，方便维护, 比selenium启动和执行速度更快.
- Jest + Playwright
- 单测
- Jest
- 纯函数的单元测试
- Jest
- 集成测试/e2e 测试
- Playwright
- 站在用户视角并且以真正的运行环境来测试整个流程和功能的,组件的单元测式升级版
- Playwright
- ui 测试
- @testing-library/react 和 @testing-library/jest-dom
- @testing-library/react 简单而完整的 React DOM 测试实用程序
- @testing-library/jest-dom 断言关于 DOM 状态的自定义匹配器。
- 目前场景不太需要
