Vitest is a Vite-native test runner: assertions, mocks, snapshots and coverage in one package, with no separate assertion library needed. Its key difference from other runners is that it runs tests through the same Vite pipeline as the application: the same transform, the same plugins, the same aliases. So Vitest understands ESM, TypeScript, JSX and the project's virtual modules out of the box - no separate transform system for tests has to be built. Its API is close to Jest (expect, describe, test), so there is almost nothing to relearn.

The runner itself installs as a single dev dependency, but two more are needed right next to it. Coverage support in Vitest is optional and lives in a separate package - @vitest/coverage-v8 for the default provider, and without it the script with the --coverage flag will not run. The vite-tsconfig-paths plugin resolves paths from tsconfig, and the config below relies on it. It helps to add three scripts to package.json. The vitest command with no arguments starts watch in the interactive terminal and reruns only the affected tests, relying on Vite's dependency graph - change a module and only the tests that touch it rerun. The vitest run command performs exactly one pass and exits. In CI always use the explicit run script: watch there simply hangs and blocks the pipeline.

The first config lives in vitest.config.ts or in the test section of a shared Vite config, and defineConfig from vitest/config types it. Start with the minimum: the environment, the file glob and a couple of mock rules. The default environment is node, and for server code that is enough; a DOM environment (jsdom or the lighter happy-dom) is wired in only where it is actually needed, and better not globally but at the level of a single project or file.

Every field of the test section reads as a decision, not a ritual. environment sets the execution environment. include is which files count as tests. globals: false keeps describe and expect explicit imports, which is easier to type and read; enabling globals saves an import line at the cost of implicitness. clearMocks resets call history between tests, restoreMocks returns originals to replaced methods - both are about isolation, which has its own chapter. coverage picks the provider (v8 by default) and the report bounds.

It helps to lay out the main options and what each one buys you once, so you do not keep it in your head or copy someone else's config blindly. Below is a short map of the fields you return to most often.