First fast test
Create one passing unit test and one failing test, then fix the failing assertion. Run once with `vitest run` and in watch mode with `vitest`.
DevOps & Tooling / Knowledge library
Vitest (vitest)
a vite-native testing framework for js/ts
Why learn Vitest (vitest)?
Vitest gives JavaScript/TypeScript teams fast, Jest-like testing with Vite-powered startup and reruns. It shortens CI feedback loops, supports mocking/snapshots/coverage, and fits modern monorepos without heavy config.
Where it came from
Created in the Vite ecosystem to provide a fast alternative to slower test runners in ESM-first projects. Adopted Jest-compatible patterns (describe/it/expect/vi) to reduce migration cost. Evolved from unit-focused usage into broader workflows: browser mode, workspaces, and CI-ready coverage/reporting.
- Created in the Vite ecosystem to provide a fast alternative to slower test runners in ESM-first projects.
- Adopted Jest-compatible patterns (describe/it/expect/vi) to reduce migration cost.
- Evolved from unit-focused usage into broader workflows: browser mode, workspaces, and CI-ready coverage/reporting.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Create one passing unit test and one failing test, then fix the failing assertion. Run once with `vitest run` and in watch mode with `vitest`.
- Write a service test that uses `vi.mock` and `mockResolvedValue` to isolate an API client. Assert call count and returned value.
- Configure coverage output for local terminal + lcov, then add a CI command that runs tests once and fails on regression.
- Given a slow suite, split tests with projects/workspace config and explain which files should run in jsdom vs node.
- Convert three plain boolean checks into idiomatic `expect` assertions (`toBe`, `toEqual`, `toContain`).
More ways to practice
Mock an async dependency
Write a service test that uses `vi.mock` and `mockResolvedValue` to isolate an API client. Assert call count and returned value.
CI-quality setup
Configure coverage output for local terminal + lcov, then add a CI command that runs tests once and fails on regression.
Debug speed bottleneck
Given a slow suite, split tests with projects/workspace config and explain which files should run in jsdom vs node.
Assertion fluency
Convert three plain boolean checks into idiomatic `expect` assertions (`toBe`, `toEqual`, `toContain`).
Documentation and sources
- Official site (vitest.dev)
- Guide (vitest.dev)
- Configuration (vitest.dev)
- Mocking (vitest.dev)
- Coverage (vitest.dev)
- CLI (vitest.dev)
Catalog research notes
- Expanded Browser Mode support for closer-to-real DOM execution.
- Faster reruns through better transform caching and watch filtering.
- Improved workspace/monorepo ergonomics for multi-project repos.
- Coverage workflows refined (v8/istanbul options, cleaner CI output).
Connect the ideas
Explore next
Real World Example
Unified Configuration for E-commerce Micro-frontends
A retail platform managing dozens of independent micro-frontends built on Vite.
The business problem
Development teams face configuration drift where production build pipelines and test environments diverge, leading to 'works in dev but fails in test' scenarios that delay deployment cycles.
How this topic solves it
By utilizing Vitest, the organization leverages the existing Vite configuration files directly within the test runner. This ensures that resolve aliases, environment variables, and plugin transformations are identical during both the build process and the execution of unit tests, eliminating environment-specific discrepancies.
- Install Vitest as a dev dependency in the root of the micro-frontend project.
- Configure the vitest.config.ts file to extend or import the existing vite.config.ts settings.
- Define test suites using the standard Vitest API, ensuring compatibility with existing Jest-like syntax.
- Integrate the vitest command into the package.json scripts to trigger watch mode during development.
- Execute tests using the shared resolution pipeline to validate component behavior against production-like settings.
This flow shows how the Vite configuration acts as a single source of truth for both production builds and testing.
Shared resolve/transform rules
Vite-native build pipeline
Test execution engine
Validated application logic
- Vite Config → provides settings → Production Build
- Vite Config → reused configuration → Vitest Runner
- Vitest Runner → generates → Test Results
Implementation example
This code demonstrates how the business scenario uses the existing vite.config.ts to maintain parity between the build and test environments.
import { defineConfig } from 'vitest/config';
import viteConfig from './vite.config';
// Reusing the existing vite configuration to ensure consistency
export default defineConfig({
...viteConfig,
test: {
globals: true,
environment: 'jsdom',
},
});Expected business outcome
Teams achieve higher confidence in test results, as the testing environment perfectly mirrors the production build pipeline, reducing the frequency of integration bugs.
Limitations and checks
Because Vitest relies on the Vite pipeline, complex custom plugins that are strictly tied to build-time assets may require conditional logic to avoid execution errors during testing. Developers can check for this by inspecting the vitest.config.ts file to ensure that plugins are correctly guarded or mocked when the environment is set to 'test'.