Vitest Testing

Vitest is a fast test runner built for Vite projects. It reuses your Vite config and transform pipeline, so tests run with the same resolution and TypeScript/ESM handling as your app — and it exposes a Jest-compatible API, so describe/it/expect and most mocking patterns work exactly as you'd expect. The payoff is very fast startup and a near-zero learning curve if you know Jest.

Use it for unit and component tests in Vite-based apps (React/Vue/Svelte). For full browser-level confidence, pair it with Playwright for E2E.

TL;DR

Quick Example

When Vitest Is a Good Fit

Vitest shines when you use Vite (React/Vue/Svelte) and want fast feedback, first-class TypeScript/ESM, and a test API that feels like Jest. If you're not on Vite, Jest is the more conventional choice.

Setup

Vitest reads your Vite config — add a test block:

Component Test (React)

Mocking: Modules, Time & Fetch

The vi object mirrors Jest's jest:

See Mocking & Stubbing.

Best Practices

Common Mistakes

Mixing ESM and CJS

Wrong environment for the test type

FAQ

How is Vitest different from Jest?

Vitest is built for Vite: it reuses your Vite config and transform pipeline, so there's no separate Babel/ts-jest setup and ESM/TypeScript "just work." It starts faster and has a Jest-compatible API (describe/it/expect, vi instead of jest). Functionally they're very similar — choose Vitest when your build is Vite, Jest otherwise.

Can I migrate from Jest to Vitest easily?

Usually yes — the APIs are intentionally close. Most tests need only jest.*vi.* renames and importing { describe, it, expect } from vitest (or enabling globals). Config moves into the test block of your Vite config. Snapshot and Testing Library usage carry over directly. Edge cases involve Jest-specific config or plugins without a Vitest equivalent.

Do I need a browser to run Vitest component tests?

No — component tests run in jsdom (a simulated DOM in Node), which is fast and sufficient for most rendering and interaction tests. When you need real-browser fidelity (layout, true event behavior, cross-browser), use Vitest's browser mode or a dedicated E2E tool like Playwright.

Should I use snapshots in Vitest?

Sparingly, for the same reasons as Jest: snapshots are easy to approve without scrutiny and drift over time. Prefer explicit assertions (getByText, toBe) for anything you can state directly, and reserve snapshots for stable serializable output where writing out the expectation by hand would be tedious.

Related Topics

References