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
- Fast test runner for Vite-based apps with a Jest-style API.
- First-class TypeScript + ESM support; reuses your Vite config.
- Test behavior (render + interactions), not implementation details.
- Mock boundaries (network, time, randomness); save real browsers for E2E.
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
- Use
jsdomfor component tests,nodefor pure logic. - Test behavior — render and interact like a user; don't assert internal state.
- Mock boundaries (network, time), let real logic run.
- Keep the project consistently ESM to avoid module-interop surprises.
- Avoid snapshot-heavy suites — easy to approve, hard to maintain.
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
- Testing — The hub
- Unit Testing — Principles
- Jest — The API Vitest mirrors
- Mocking & Stubbing —
vimocks - Playwright — E2E pairing