前端自动化测试

/**

 * 1. 测试是什么?

 * 保证程序在运行过程中是正确的。

 * 核心：输入 —— 预期输出 —— 验证结果

 *

 * 2. 种类

 *   a、手动测试（问题：若程序复杂, 人为测试会遗漏部分逻辑，从而导致发布线上出现错误）

 *   b、自动化测试

 *

 * 3. 前端自动化测试是什么?

 * 答：测试金字塔型：从下到上依次为，越往上，开发者越容易获得成就感，一个系统不仅限于一种测试，根据不同场景搭配不同的测试

 *    5. 测试覆盖率（行，函数，分支，语句的覆盖，分支指的是if, else, 共有几个条件，哪个条件执行了，按照%占比计算，方便观察覆盖率情况）

 *    4. 快照测试（验证程序的UI变化）

 *    3. 端到端测试（从用户角度，使用机器在真实浏览器环境验证应用交互）

 *    2. 集成测试 （验证多个单元协同工作）

 *    1. 单元测试（验证独立的单元是否正常，单元代表一个函数，一个组件）

 *    0. 静态测试（Eslint，typeScript 验证代码质量和代码规范）

 *

 *    a、单元测试（Jest）

 *       优点：

 *       1. 代码覆盖率高

 *       2. （写）代码质量高，bug少

 *       3. （测试）快速反馈，减少测试时间

 *       4. （维护）更容易维护

 *       缺点：

 *       1. 仅用于独立的单元，无法保证多个单元在程序运行期间是正常的

 *       适用范围：

 *       1. 函数，组件

 *    b、集成测试（Jest）

 *       优点：

 *       1、从用户角度出发，编写测试代码，更符合软件程序

 *       2、不关注单元细节，快速重构

 *       3、开发速度较单元测试快

 *       缺点：

 *       1、测试失败时，无法快速定位问题

 *       2、代码覆盖率低

 *       3、测试速度比单元测试慢

 *       适用范围：

 *       1. 函数之间，组件之间

 *     c、端到端测试（cypress）

 *       优点：

 *       1. 在浏览器的真实环境，用机器测试代码

 *       2. 与手动测试相比，机器测试速度更快，更准确，减少人力做回归测试

 *       3、仅用于核心且稳定的逻辑做E2E测试

 *       缺点：

 *       1、运行速度慢（启动浏览器，网络请求）

 *       2、调试困难（本地调试，集成服务器调试）

 *       适用范围：

 *       1、登录，退出登录，表单（新增, 编辑, 删除），点赞，收藏，模仿用户行为

 *     d、快照测试

 *       优点：

 *       1、新拍摄的截图与已保存的截图，对比找不同

 *       适用范围：

 *       1、已经封装好的组件，后期在UI上不会更改

 *

 * 场景：通常用于前端封装的组件，核心代码，逻辑极少更改的代码。

 *

 * 2. 为什么要用?（方便维护，减少测试时间，方便重构）

 *    a、方便后期需求变更时，代码更容易维护。

 *    b、代码发生变动, 及时错误指出。

 *    c、减少发布线上前人为测试时间，回归测试更省心

 *    d、促进重构

 *    f、提升程序健壮性，稳定性

 *

 * 3. 怎么用?

 *    a、vitest 测试库, vite 支持, 若使用 vite ,  vitest 与其更搭配？

 *    b、jest 测试库，功能较全？

 *

 * 4. 缺点?

 *    a、前期需要花费大量的时间编写测试用例, 测试代码，耗时，成本高

 *    b、代码量大，造成打包缓慢，加载速度慢

 *    c、逻辑简单的系统，不建议使用，大材小用

 *

 *

 * 5、测试开发方式

 *    a、TDD 测试驱动开发（白盒测试）

 *      核心：

 *         1、先写测试再写功能

 *         2、编写独立的测试用例，如某个功能点，某个函数

 *      优点：

 *         1、代码质量高

 *         2、有利于程序的模块设计

 *         3、测试覆盖率高

 *      缺点：

 *         1、代码量多

 *         2、更关注某个单元，多个单元程序运行无法确保是否正常

 *         3、代码耦合度高，后期需求变更，测试代码同步更改

 *         4、与实际功能需求相差比较大

 *

 *    b、BDD 行为驱动开发（黑盒测试）

 *      核心：

 *         1、先写功能再写测试

 *         2、从需求出发，编写测试代码

 *      优点：

 *         1、如果要修改逻辑，输入输出不变，内部逻辑更改，不影响测试流程

 *         2、更关注功能测试，也就是黑盒测试

 *         3、通过Cucumber软件，产品与开发确认需求，以 Cucumber 文本的格式确认

 *

 *    c、TDD + BDD（推荐使用）

 *

 * 6、Jest

 *      主要特点：零配置、自带断言、测试覆盖率、快照测试、Mock模拟、前端技术不局限、只执行发生改变文件所对应的测试

 *

 * 7、Vue Testing Library

 *      核心: 测试将不使用渲染的 Vue 组件实例，而是使用实际的 DOM 节点。

 *

 * 8、Vue Test Utils（VTU）

 *      是什么? 是一组实用程序函数，在简化Vue.js组件的测试。它提供了一些以隔离方式挂载 Vue 组件并与之交互的方法。

 *

 * 9、Vitest

 *      特点:

 *          1、基于Vite驱动

 *          2、与Jest兼容

 *          3、智能且即时的监视模式

 *          4、ESM，TypeScript，JSX支持

 *          5、更快地运行单元测试（默认使用 vite 即时热模块重载）

 *          6、将开发、构建和测试环境的配置定义为一个管道，共享相同的插件和 vite.config.js 文件

 *          7、Cypress 的测试更加专注于确定浏览器中UI元素是否可见，Vitest用于非浏览器逻辑的单元测试（浏览器APIs代码进行单元测试），结合使用端到端和组件测试更合适

 *

 * 10、Vue Test Utils 和 Vitest 结合使用

 */

遇到问题：

1. TypeError: Unknown file extension ".scss" for D:\workspace\ai_plat_front\node_modules\element-plus\theme-chalk\src\base.scss

Serialized Error: { code: 'ERR_UNKNOWN_FILE_EXTENSION' }

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

vite.config.js (蓝色部分，为修改内容)/// <reference types="vitest" />   /* eslint-disable */ const timestamp = new Date().getTime()   export default defineConfig(({ command, mode, ssrBuild }) => {     return {         // 其他配置         test: {             // 启用类似 jest 的全局测试 API             globals: true,             // 使用 happy-dom 模拟 DOM             // 这需要你安装 happy-dom 作为对等依赖（peer dependency）             environment: 'happy-dom',             server: {                 deps: {                     inline: ['element-plus']                 }             }         }     } })