技能介绍

解决什么问题

在 Vite 项目里，测试往往会变成“第二套构建配置”。开发时源码经过 Vite 的解析、转译和别名处理，单元测试却还要为 Jest 单独配置 transform、ESM、路径映射，有时还要维护 ts-jest/Babel 之类的额外链路。结果不是测试本身难写，而是配置和迁移成本高：TS 类型项目要等待转译规则对齐，Vite alias/插件难以直接复用，watch 模式启动和热更新体验与开发不一致，已有 Jest 用例也因为 API 差异要改。

Vitest 的思路是把 Vite 的模块处理能力直接接进测试运行时。测试代码不需要绕开 Vite 再走一套转换流程，而是沿用同一套解析与 transform 思路，从而减少“开发能跑、测试不能跑”的割裂。

核心能力与工作方式

Vite 驱动：测试执行基于 Vite 的解析和转换能力，项目里的模块别名、插件和解析规则更容易保持一致。
原生 ESM / TypeScript：直接面向 ESM 工作，TS 项目无需额外搭建测试转译链路。
Jest 兼容 API：describe、it、expect 等常见结构保持一致，现有 Jest 风格的用例迁移成本较低。
浏览器运行：除了 Node 环境，也可以把测试放到真实浏览器中执行，适合需要 DOM、布局或浏览器 API 的验证场景。

典型流程是：沿用项目现有 Vite 配置定义测试入口，用 Jest 风格组织用例，然后在 Node 或浏览器中运行，并根据反馈做 watch、筛选和持续回归。

适用边界与注意点

它更适合 Vite 技术栈，或希望让开发、测试共享同一套模块解析约定的项目。对已有 Jest 用例比较友好，但如果项目深度依赖自定义 resolver、matcher、snapshot 或 coverage 行为，迁移前仍应验证兼容性。运行环境也需要满足上游要求，当前资料给出的门槛是 Vite >= v6.4.0、Node >= v22.12.0。另外，浏览器模式能更贴近真实 DOM，但复杂用户旅程和跨系统验证通常仍需要端到端测试。