Vitest is a next-generation JavaScript and TypeScript testing framework powered by Vite, built for teams already running Vite who want Jest-compatible tests without maintaining a second, separate build pipeline.
What it is
Vitest is a testing framework that reuses the Vite config, transformers, resolvers, and plugins a project already has, so tests run through the same pipeline as the application. The same setup used for the app applies to the tests, which means aliases, TypeScript, JSX, and plugin behaviour do not need to be duplicated or re-declared in a test-only configuration. It is written in TypeScript, lives in the Vite ecosystem, and is maintained under the MIT licence by VoidZero Inc. and Vitest contributors.
The concrete problem it solves is the drift between an application's build configuration and its test configuration. Before Vitest, Vite projects typically paired Vite for the app with Jest for tests, then spent effort bridging the two: transposing module resolution, mapping aliases, and keeping two transform stacks consistent. Vitest replaces that split setup. It consumes Vite's config directly, ships Chai built in for assertions alongside Jest expect compatible APIs, and provides Jest-compatible mocking, stubbing, and spies, so existing Jest-style test suites need little or no rewriting. It is ESM first, supports top-level await, and includes snapshot testing compatible with Jest Snapshot.
Key capabilities
- Reuses Vite's config, transformers, resolvers, and plugins, so the app and the test suite share one setup.
- Chai built in for assertions, with Jest
expect compatible APIs, including expect(...).toEqual(...), expect(...).to.be.true, and assert.equal(...).
- Jest Snapshot support through matchers such as
toMatchSnapshot().
- Native code coverage via
v8 or istanbul.
- Smart and instant watch mode, described as HMR for tests.
- JSDOM and happy-dom for DOM and browser API mocking, plus a Browser Mode for running component tests in a real browser.
- Component testing examples for Vue, React, Svelte, Lit, and Marko, with benchmarking via Tinybench,
expect-type for type-level testing, Projects support, filtering, timeouts, concurrent suites and tests, and sharding.
Who uses it and how
- Vite application teams that want one build pipeline for both app and tests, rather than running Jest alongside Vite.
- Library authors testing components across Vue, React, Svelte, Lit, and Marko, using Browser Mode when DOM emulation is not enough.
- Projects migrating from Jest that want to keep snapshots, mocks, spies, and
expect-style assertions while moving to an ESM-first, TypeScript-native runner.
- Teams running large suites in CI, using sharding to spread tests across parallel jobs and native
v8 or istanbul coverage for reporting.
- Developers in local watch loops, relying on instant watch mode to rerun affected tests as files change.
Getting started
Install and run the vitest package, typically with npx vitest in a project that already has Vite. Full guidance lives in the documentation at vitest.dev, which covers Getting Started, features, and browser mode.
How it compares
The README names Jest as the source of the testing API it stays compatible with, and credits uvu as an inspiration for its approach, positioning Vitest as the Vite-native alternative to running those tools separately. It also builds on Chai for assertions, istanbul and the V8 coverage facility for coverage, and Tinybench for benchmarking, so it composes existing ecosystem pieces rather than replacing them. Where it differs from Jest is the pipeline: Vitest reuses Vite's config and plugins instead of requiring a parallel transform setup.
When to use it — and when not to
Vitest requires Vite >= v6.4.0 and Node >= v22.12.0, so projects pinned to older Node or Vite releases cannot adopt it without upgrading those runtimes first. It is a strong fit for Vite applications, but teams not using Vite lose the central benefit of shared configuration, and those needing a runner decoupled from a specific build tool should weigh that. Self-hosters operate no database or storage service for Vitest itself, though CI sharding and coverage reporting are their own infrastructure to run; the repository also carries 425 open issues, and the README is a short feature list that delegates most detail to the external vitest.dev documentation.