尧图网站建设 
别再干等测试跑完用 Vitest 3 步跑通你的 Vite 项目【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest凌晨两点 CI 变红日志写着测试超时。查下来发现40 个测试文件只引用了 3 个工具函数import 阶段却占了总耗时 40%。Vitest 是 Vite 驱动的测试框架与应用共享同一条转换管道开启模块缓存后二次运行能从 8.75s 降到 5.90s。和 Jest 差在哪维度VitestJest典型配置转换管道复用 Vite与vite.config同一份babel-jest需单独维护 transforms模块处理原生 ESM按需转换CJS 互操作大项目要额外 preset默认模式watch 默认开启只重跑受影响测试一次性运行watch 需手动打开性能诊断耗时按阶段拆分vitest doctor实测替代配置主要靠经验调参说白了差别不在快一点而在测试和应用走同一条管道第二套转换配置直接省掉。3 步跑通第一个用例第 1 步安装。需要 Node ≥ 22.12.0、Vite ≥ 6.4.0npm install -D vitest装进现有 Vite 项目后它会直接读取你的vite.config.ts别名、环境变量、插件全部共享这一步不需要写任何配置。第 2 步写测试文件。文件名默认要包含.test.或.spec.// src/sum.test.js import { expect, test } from vitest import { sum } from ./sum.js test(adds 1 2 to equal 3, () { expect(sum(1, 2)).toBe(3) })第 3 步跑起来。在package.json里加test: vitest执行npm test。首次运行默认进 watch 模式改动代码只会重跑受影响的文件想直观看结果加--ui参数在浏览器里打开界面断言失败会直接给出 diff。测试时间花在哪了看一次运行的结尾Duration 3.76s (environment 79%, import 13%, transform 6%, tests 1%)这是 Vitest 性能诊断的入口总耗时被拆成 environment、transform、import、setup、worker 五个阶段每个阶段各对应一类配置。为什么同一个工具函数会被加载 40 次其实根源是隔离。默认情况下每个测试文件都跑在独立环境里forks池是独立子进程threads池是独立 worker。它防止了文件间状态串味但代价是每个文件都要重新付一遍所有成本jsdom 光构建就要 200-500ms。environment占比高问题基本出在这。第二个大头是 import。按需转换相当于点一道菜炒一道菜但桶文件barrel file用 index.ts 导出整个目录会把整张模块图拖进来隔离模式下每个测试文件都重复求值一遍这张共享图。怎么配三步。看百分比下手。environment 占比高、测试又不依赖干净的 window设isolate: false是最快方案若每个文件都需要新 window换pool: vmThreads环境按 worker 建一次。让缓存落盘。内存缓存在运行结束就丢弃开启fsModuleCache后写入文件系统小范围重跑大模块图从 8.75s 降到 5.90s。揪出桶文件。开启experimental.diagnostics看终端输出的 Import Duration Breakdown Top 10把from ../src/utils这类整目录导入改成直接导入。拿不准哪套组合更好时vitest doctor会用每种候选配置实际跑一遍你的套件给出对比结果甚至告诉你isolate: false下测试是否仍然通过。更多选项见 性能优化章节。订单服务里怎么 mock 外部支付订单服务依赖外部支付网关测试不可能真调网关。用vi.mock把pay换成受控函数// order.service.js import { pay } from ../payment/gateway.js export async function createOrder(items) { try { const receipt await pay(items) return { status: paid, receipt } } catch { return { status: pending } } }// order.service.test.js import { test, expect, vi } from vitest import { createOrder } from ./order.service.js import { pay } from ../payment/gateway.js vi.mock(../payment/gateway.js, () ({ pay: vi.fn() })) test(支付成功返回单号, async () { pay.mockResolvedValueOnce({ id: R1001 }) const order await createOrder([{ sku: A1, qty: 1 }]) expect(order.receipt.id).toBe(R1001) }) test(支付失败标记为待处理, async () { pay.mockRejectedValueOnce(new Error(timeout)) const order await createOrder([{ sku: A1, qty: 1 }]) expect(order.status).toBe(pending) })⚠️ 踩坑提示vi.mock声明会被提升到文件顶部执行factory 里不要直接引用后定义的外部变量否则抛 ReferenceError需要这类共享状态时用vi.hoisted(() ...)声明。避坑手册模块找不到症状Cannot find module尤其从 Jest 迁移后/helpers这类写法报错。 根因路径别名靠 tsconfig 的baseUrlVite 默认不读取它。 修复装vite-tsconfig-paths插件挂到 plugins或改成相对路径。进程跑完不退出症状Failed to terminate worker。 根因pool: threads下使用 Node 全局 fetch句柄挂住线程。 修复改回默认的pool: forks或用vmForks。重跑还是慢症状watch 里飞快运行结束后下次完整运行照样慢。 根因转换缓存只在内存运行结束即丢弃。 修复开启fsModuleCache落盘CI 里再配合缓存NODE_COMPILE_CACHE目录。收束回到开头那个凌晨两点的 CI先看 Duration 的五个阶段再用vitest doctor实测着改配置environment 和 import 两个大头都有明确的收敛方向。性能诊断与调优docs/guide/improving-performance.mdMock 体系docs/guide/mocking.md完整配置参考docs/config/index.md本文基于本仓库当前文档撰写。Vitest 要求 Node ≥ 22.12.0、Vite ≥ 6.4.0jsdom 每文件 200-500ms、happy-dom 90-200ms 的环境构建耗时与 8.75s → 5.90s 的缓存对比数据均出自官方性能文档。【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 别再干等测试跑完：用 Vitest 3 步跑通你的 Vite 项目
别再干等测试跑完用 Vitest 3 步跑通你的 Vite 项目【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest凌晨两点 CI 变红日志写着测试超时。查下来发现40 个测试文件只引用了 3 个工具函数import 阶段却占了总耗时 40%。Vitest 是 Vite 驱动的测试框架与应用共享同一条转换管道开启模块缓存后二次运行能从 8.75s 降到 5.90s。和 Jest 差在哪维度VitestJest典型配置转换管道复用 Vite与vite.config同一份babel-jest需单独维护 transforms模块处理原生 ESM按需转换CJS 互操作大项目要额外 preset默认模式watch 默认开启只重跑受影响测试一次性运行watch 需手动打开性能诊断耗时按阶段拆分vitest doctor实测替代配置主要靠经验调参说白了差别不在快一点而在测试和应用走同一条管道第二套转换配置直接省掉。3 步跑通第一个用例第 1 步安装。需要 Node ≥ 22.12.0、Vite ≥ 6.4.0npm install -D vitest装进现有 Vite 项目后它会直接读取你的vite.config.ts别名、环境变量、插件全部共享这一步不需要写任何配置。第 2 步写测试文件。文件名默认要包含.test.或.spec.// src/sum.test.js import { expect, test } from vitest import { sum } from ./sum.js test(adds 1 2 to equal 3, () { expect(sum(1, 2)).toBe(3) })第 3 步跑起来。在package.json里加test: vitest执行npm test。首次运行默认进 watch 模式改动代码只会重跑受影响的文件想直观看结果加--ui参数在浏览器里打开界面断言失败会直接给出 diff。测试时间花在哪了看一次运行的结尾Duration 3.76s (environment 79%, import 13%, transform 6%, tests 1%)这是 Vitest 性能诊断的入口总耗时被拆成 environment、transform、import、setup、worker 五个阶段每个阶段各对应一类配置。为什么同一个工具函数会被加载 40 次其实根源是隔离。默认情况下每个测试文件都跑在独立环境里forks池是独立子进程threads池是独立 worker。它防止了文件间状态串味但代价是每个文件都要重新付一遍所有成本jsdom 光构建就要 200-500ms。environment占比高问题基本出在这。第二个大头是 import。按需转换相当于点一道菜炒一道菜但桶文件barrel file用 index.ts 导出整个目录会把整张模块图拖进来隔离模式下每个测试文件都重复求值一遍这张共享图。怎么配三步。看百分比下手。environment 占比高、测试又不依赖干净的 window设isolate: false是最快方案若每个文件都需要新 window换pool: vmThreads环境按 worker 建一次。让缓存落盘。内存缓存在运行结束就丢弃开启fsModuleCache后写入文件系统小范围重跑大模块图从 8.75s 降到 5.90s。揪出桶文件。开启experimental.diagnostics看终端输出的 Import Duration Breakdown Top 10把from ../src/utils这类整目录导入改成直接导入。拿不准哪套组合更好时vitest doctor会用每种候选配置实际跑一遍你的套件给出对比结果甚至告诉你isolate: false下测试是否仍然通过。更多选项见 性能优化章节。订单服务里怎么 mock 外部支付订单服务依赖外部支付网关测试不可能真调网关。用vi.mock把pay换成受控函数// order.service.js import { pay } from ../payment/gateway.js export async function createOrder(items) { try { const receipt await pay(items) return { status: paid, receipt } } catch { return { status: pending } } }// order.service.test.js import { test, expect, vi } from vitest import { createOrder } from ./order.service.js import { pay } from ../payment/gateway.js vi.mock(../payment/gateway.js, () ({ pay: vi.fn() })) test(支付成功返回单号, async () { pay.mockResolvedValueOnce({ id: R1001 }) const order await createOrder([{ sku: A1, qty: 1 }]) expect(order.receipt.id).toBe(R1001) }) test(支付失败标记为待处理, async () { pay.mockRejectedValueOnce(new Error(timeout)) const order await createOrder([{ sku: A1, qty: 1 }]) expect(order.status).toBe(pending) })⚠️ 踩坑提示vi.mock声明会被提升到文件顶部执行factory 里不要直接引用后定义的外部变量否则抛 ReferenceError需要这类共享状态时用vi.hoisted(() ...)声明。避坑手册模块找不到症状Cannot find module尤其从 Jest 迁移后/helpers这类写法报错。 根因路径别名靠 tsconfig 的baseUrlVite 默认不读取它。 修复装vite-tsconfig-paths插件挂到 plugins或改成相对路径。进程跑完不退出症状Failed to terminate worker。 根因pool: threads下使用 Node 全局 fetch句柄挂住线程。 修复改回默认的pool: forks或用vmForks。重跑还是慢症状watch 里飞快运行结束后下次完整运行照样慢。 根因转换缓存只在内存运行结束即丢弃。 修复开启fsModuleCache落盘CI 里再配合缓存NODE_COMPILE_CACHE目录。收束回到开头那个凌晨两点的 CI先看 Duration 的五个阶段再用vitest doctor实测着改配置environment 和 import 两个大头都有明确的收敛方向。性能诊断与调优docs/guide/improving-performance.mdMock 体系docs/guide/mocking.md完整配置参考docs/config/index.md本文基于本仓库当前文档撰写。Vitest 要求 Node ≥ 22.12.0、Vite ≥ 6.4.0jsdom 每文件 200-500ms、happy-dom 90-200ms 的环境构建耗时与 8.75s → 5.90s 的缓存对比数据均出自官方性能文档。【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考