前端技术演化史

Vitest

Properties1
tags测试, vitest, vite, unit-test, esm, 工具链统一

8分钟阅读

⚡ Vitest

一句话定性

Vitest 的存在理由可以浓缩成一句话:“你的应用已经用 Vite 转换代码了,为什么测试还要再养一套 Jest 的转换管线?” 它复用 Vite 的同一套配置和转换管线来跑测试,顺手抄了 Jest 的全部 API。这和 Vite 取代 Webpack 是同一个第一性原理的两次应用:消灭重复的、不一致的管线。

一、它是什么 & 出现的时代

Vitest 是 2021 年诞生的、基于 Vite 的单元测试框架(由 Vite/Vue 生态核心成员发起)。它生于 2018-2023 工程化时代 的尾声——彼时 Vite 已成新项目默认,但测试层还卡在 Jest 时代,应用和测试用着两套不同的构建逻辑,矛盾积累到需要一个原生方案。

Vitest 不是”又一个测试框架”,它是把测试这件事并入 Vite 管线的产物。

二、为什么会出现(解决上一代什么痛点)

Jest 在 Vite 项目里"水土不服"

当你的应用迁到 Vite,测试若继续用 Jest,就会撞上一堵墙:

  1. 两套转换管线,且不一致:应用代码由 Vite(esbuild/Rollup + 你的 vite.config.ts 里的插件、别名、define)转换;Jest 却走自己的 babel-jest/ts-jest。同一份源码,被两套规则处理,行为可能不同——“应用里能跑、测试里报错”。
  2. 配置要写两遍:别名(alias)、环境变量、JSX/TS 转换、插件,在 vite.config 里配过一遍,还得在 jest.config 里再配一遍并保持同步。配置漂移(config drift)是 bug 温床。
  3. Jest 对原生 ESM 支持长期别扭:现代代码全是 ESM,Jest 的 ESM 支持长期处于实验/需绕路状态,而 Vite 的世界本就是原生 ESM。

本质矛盾:测试环境和生产/开发环境必须”长得一样”才有意义,但 Jest 与 Vite 是两套世界观。

三、核心机制 & 为什么流行

Vitest 的设计就一句话:复用 Vite,兼容 Jest

① 复用 Vite 的配置与转换管线(灵魂) Vitest 直接读你的 vite.config.ts——同样的插件、别名、define、TS/JSX 转换。配一次,应用和测试共用。测试看到的代码,就是应用看到的代码,行为一致,config drift 消失。

② 原生 ESM + 极快 站在 Vite 肩上:esbuild 转换、按需编译、智能 watch(只重跑受影响的测试)、HMR 式的测试热更新。反馈速度比 Jest 明显更快,尤其在 watch 模式下。

③ 几乎 100% 兼容 Jest API(迁移成本极低) describe / it / expect / vi.fn() / vi.mock()、快照、覆盖率——API 设计刻意对齐 Jest(jest → vi)。存量 Jest 测试常常改几行 import 就能跑。这是它快速普及的关键:不要求开发者重新学一套。

④ 同样基于 jsdom/happy-dom 或浏览器模式 默认仍可用 jsdom/happy-dom 模拟环境(继承 Jest 那套权衡),也提供 browser mode 在真实浏览器里跑。

Vite 项目 + Jest(分裂):
   vite.config(应用) ─┐
                      ├─ 两套规则,需手动同步,行为可能不一致
   jest.config(测试) ─┘

Vite 项目 + Vitest(统一):
   vite.config ──► 应用 与 测试 共用同一套转换  ◄── 配一次,行为一致

四、带来的新问题 / 副作用

统一管线不是没有代价

  1. 强绑定 Vite 生态:Vitest 的前提是”你已经在用 Vite”。非 Vite 项目(Webpack/CRA/部分 Next.js)用它收益有限,Jest 仍更自然。
  2. 继承了 jsdom 的”非真浏览器”原罪:默认 jsdom/happy-dom 环境,和 Jest 一样有”模拟环境 ≠ 真浏览器”的信心折扣;browser mode 更真但更慢、仍在成熟中。
  3. 年轻带来的生态缺口:相比 Jest 多年沉淀,Vitest 的第三方插件、报告器、踩坑文档相对少(但追赶很快)。
  4. 与 Jest 的细微 API 差异:99% 兼容不等于 100%,大型迁移仍可能遇到边角 case。

五、为什么会衰落 / 现状

Vitest 远未衰落,处于强势上升期:Vite 生态(Vue、Vite-based React、Svelte、Astro 等)的默认测试方案正集体倒向它。

现状(2026)

  • Vite 生态的事实标准:新建 Vite 项目时,脚手架普遍预置 Vitest 而非 Jest。
  • 正在补真实性短板:browser mode 持续成熟,试图同时拿下”配置统一(对 Jest)“和”真浏览器(对 jsdom)“两个优势。
  • 格局:Jest 守存量(Webpack/CRA/老项目),Vitest 拿增量(Vite 新项目)。这条分界线和 Webpack vs Vite 几乎重合——测试工具的版图,正在被构建工具的版图重新划定。

六、对后续技术的影响(因果链)

[[Vite]] 成为新项目默认(no-bundle dev + esbuild/Rollup)
        │
        ▼  但测试层仍用 [[Jest与单元测试|Jest]] 的独立管线
        │
矛盾:应用与测试两套转换 ──► 不一致 + 配置写两遍 + Jest 的 ESM 痛
        │
        ▼  第一性原理(同 [[为什么Vite能取代Webpack]]):消灭重复管线
        │
Vitest(2021):复用 vite.config + 兼容 Jest API
        │  ① 配一次,应用/测试行为一致 ──► 消灭 config drift
        │  ② 原生 ESM + esbuild ──► 极快
        │  ③ Jest API 兼容 ──► 迁移成本≈0,快速普及
        │
        ├──► 成为 Vite 生态默认测试方案,蚕食 Jest 增量
        │
        └──► 印证"工具链统一"潮:构建/测试合流(延续 [[Vite]] 的逻辑)

历史地位

Vitest 的意义不在”又快了多少”,而在它揭示了一条规律:当构建工具统一了,测试工具迟早会被它吸附过去。Vite 在 dev 层问”为什么要先打包”,Vitest 在测试层问”为什么要养第二套管线”——同一种”质疑重复前提”的思维,在前端工具链里一再奏效(参见 为什么Vite能取代Webpack)。

🔗 相关:前端测试演进史 | Jest与单元测试 | Testing-Library与组件测试 | E2E测试-Cypress与Playwright 🔗 工程化(强相关):Vite | Webpack | TypeScript | 为什么Vite能取代Webpack 🔗 运行时:Node.js | 框架:Vue | React 🔗 时代:2018-2023 工程化时代

关系图谱

反向链接