Vitest Testing

Vitest is a modern test runner designed for Vite projects. It's fast, ESM-native, and provides a Jest-compatible API with better TypeScript support and instant HMR-powered watch mode.

When to Use This Skill

Core Expertise

• Vite-native: Reuses Vite config, transforms, and plugins
• Fast: Instant feedback with HMR-powered watch mode
• Jest-compatible: Drop-in replacement with similar API
• TypeScript: First-class TypeScript support
• ESM: Native ESM support, no transpilation needed
• jsdom DOM tests: and the assertions that silently lie under it (see below)

Installation

bun add --dev vitest
bun add --dev @vitest/coverage-v8      # Coverage (recommended)
bun add --dev happy-dom                # DOM testing (optional)
bunx vitest --version                  # Verify

Configuration (vitest.config.ts)

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'node',
  },
});

Essential Commands

bunx vitest                            # Watch mode (default)
bunx vitest run                        # Run once (CI mode)
bunx vitest --coverage                 # With coverage
bunx vitest src/utils.test.ts          # Specific file
bunx vitest -t "should add numbers"    # Filter by name
bunx vitest related src/utils.ts       # Related tests
bunx vitest -u                         # Update snapshots
bunx vitest bench                      # Benchmarks
bunx vitest --ui                       # UI mode

Writing Tests

Basic Test Structure

import { describe, it, expect } from 'vitest';
import { add, multiply } from './math';

describe('math utils', () => {
  it('should add two numbers', () => {
    expect(add(2, 3)).toBe(5);
  });

  it('should multiply two numbers', () => {
    expect(multiply(2, 3)).toBe(6);
  });
});

Key Assertions

Async Tests

test('async test', async () => {
  const data = await fetchData();
  expect(data).toBe('expected');
});

test('promise resolves', async () => {
  await expect(fetchData()).resolves.toBe('expected');
});

test('promise rejects', async () => {
  await expect(fetchBadData()).rejects.toThrow('error');
});

DOM tests under jsdom — assertions that lie

environment: 'jsdom' gives you a DOM without a layout engine, and its CSS parser is narrower than a browser's. Several natural-looking assertions are therefore vacuous: they pass against the very bug they were written to catch, and read as coverage so nobody looks again.

Also: Element.prototype.scrollIntoView does not exist in jsdom, so any code path that centres an element throws on mount. Stub it (Element.prototype.scrollIntoView = () => {}) — that is a harness gap, not a behaviour change.

And never write a conditional assertion:

// Passes silently in exactly the case it was meant to catch — a renamed class.
if (found.length === 1) expect(found[0].textContent).toMatch(/x/);

// Assert unconditionally.
expect(found).toHaveLength(1);
expect(found[0].textContent).toMatch(/x/);

Make it fail on purpose

A regression test that has never failed has not been shown to test anything. Before trusting one, force red and read the message:

• Fix in this package → revert the fix in place, confirm red for the right reason, restore.
• Cross-package suite → re-pin the dependency to the release before the fix, confirm red, restore the pin.

Record the observed failure output in the PR body. "It goes red" is a claim; the message is the evidence.

Loading a sibling package's source for a real integration test

When a defect is a property of two packages together, testing each against a stand-in keeps both green while the pair is broken. To load a sibling's real source:

1. depend on it pinned to a release tag (e.g. a git dependency), so the suite tests a published artifact rather than a moving branch;
2. add it to server.deps.inline — vitest externalizes node_modules by default and would hand Node raw TypeScript:

export default defineConfig({
  test: { server: { deps: { inline: [/sibling-package/] } } },
});

3. export the host's real entry point, so the suite drives the actual code path rather than a per-unit seam where the bug cannot appear.

Mocking (Essential Patterns)

import { vi, test, expect } from 'vitest';

// Mock function
const mockFn = vi.fn();
mockFn.mockReturnValue(42);

// Mock module
vi.mock('./api', () => ({
  fetchUser: vi.fn(() => Promise.resolve({ id: 1, name: 'John' })),
}));

// Mock timers
vi.useFakeTimers();
vi.advanceTimersByTime(1000);
vi.restoreAllMocks();

// Spy on method
const spy = vi.spyOn(object, 'method');

Snapshot Testing

test('snapshot test', () => {
  expect(data).toMatchSnapshot();
});

test('inline snapshot', () => {
  expect(result).toMatchInlineSnapshot('5');
});
// Update snapshots: bunx vitest -u

Coverage

bun add --dev @vitest/coverage-v8
bunx vitest --coverage

Key config options: provider, reporter, include, exclude, thresholds.

Agentic Optimizations

For detailed examples, advanced patterns, and best practices, see REFERENCE.md.

References

• Official docs: https://vitest.dev
• Configuration: https://vitest.dev/config/
• API reference: https://vitest.dev/api/
• Migration from Jest: https://vitest.dev/guide/migration.html
• Coverage: https://vitest.dev/guide/coverage.html