MCPInstall

vitest-v4

Vitest 4+ testing with Vite. Use when configuring vitest.config.ts, writing unit/integration/browser tests, implementing mocks with vi.fn/vi.spyOn/vi.mock, setting up V8 or Istanbul coverage, or migrating from Jest or older Vitest workspace setups. Triggers on vitest, vitest.config.ts, vi.mock, browser mode, vitest/browser, projects, setupFiles, and toMatchScreenshot.

Installs
62
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/nodnarbnitram/claude-code-extensions --skill vitest-v4
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads vitest-v4 automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Vitest 4 Testing Skill

Write, configure, and debug Vitest 4 test suites with Vite-native patterns.

Before You Start

This skill prevents 7+ common Vitest 4 mistakes and saves ~50% tokens.

MetricWithout SkillWith Skill
Setup Time~90 min~30 min
Common Errors7+0
Token UsageHigh (trial/error)Low (known patterns)

Known Issues This Skill Prevents

  1. Hanging agent runs from using watch mode instead of vitest run
  2. Broken coverage configs from using removed coverage.all or coverage.extensions
  3. Browser Mode spying failures from sealed ESM namespace objects
  4. Mock leakage between tests from missing restore/reset config
  5. Invalid multi-project setup from using deprecated workspace terminology
  6. Wrong APIs from mixing Jest helpers into Vitest tests
  7. Flaky browser interactions from using synthetic helpers instead of vitest/browser
  8. Slow or unstable large suites from choosing the wrong execution pool or isolation mode

Quick Start

Step 1: Configure Vitest 4 for agent-safe runs

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environment: 'node',
    restoreMocks: true,
    clearMocks: true,
    coverage: {
      provider: 'v8',
      include: ['src/**/*.{ts,tsx}'],
    },
  },
});

Why this matters: Vitest 4 removed coverage.all and coverage.extensions, and agent/CI environments need one-shot execution plus automatic mock cleanup.

Step 2: Write tests with Vitest APIs, not Jest APIs

import { describe, expect, it, vi } from 'vitest';
import { addUser } from './add-user';
import * as api from './api';

describe('addUser', () => {
  it('returns the created user', async () => {
    vi.spyOn(api, 'createUser').mockResolvedValue({ id: '1', name: 'Ada' });

    await expect(addUser('Ada')).resolves.toEqual({ id: '1', name: 'Ada' });
  });
});

Why this matters: vi is the supported mocking API. Mixing jest.fn() or Jest-only patterns causes confusing failures and poor autocomplete.

Import rule: Import describe, it, expect, and vi from vitest unless the project explicitly enables globals: true.

Step 3: Use the correct runtime command

vitest run
vitest run --coverage
vitest run path/to/example.test.ts

Why this matters: vitest without run starts watch mode by default in development, which is a poor fit for agents, CI, and non-interactive verification.

Critical Rules

Always Do

  • Use vitest run or vitest --no-watch for agent and CI workflows
  • Prefer vi.mock(import('./module')) for type-safe module mocks
  • Configure restoreMocks, clearMocks, or mockReset intentionally
  • Use projects for multi-project configs; the rename began in Vitest 3.2 and older workspace-file usage is removed in Vitest 4
  • Use a shared base config when multiple projects need common settings; projects do not inherit root config unless you opt in
  • Use coverage.include to report on untested source files
  • Use page and userEvent from vitest/browser in Browser Mode
  • Prefer forks when native modules or runtime compatibility matter more than raw speed
  • Share vitest.config.ts and the implementation file when asking AI to generate tests

Never Do

  • Never use jest.fn, jest.spyOn, or Jest-only globals in Vitest code
  • Never rely on removed coverage.all or coverage.extensions in Vitest 4
  • Never use plain watch mode for agent-driven verification
  • Never use vi.spyOn on native ESM exports in Browser Mode
  • Never forget that vi.mock() is hoisted before the rest of the file executes
  • Never leave env/global stubs un-restored across tests

Common Mistakes

Wrong - removed coverage option:

export default defineConfig({
  test: {
    coverage: {
      all: true,
    },
  },
});

Correct - use include globs:

export default defineConfig({
  test: {
    coverage: {
      provider: 'v8',
      include: ['src/**/*.{ts,tsx}'],
    },
  },
});

Why: Vitest 4 removed coverage.all and coverage.extensions; coverage.include is the supported way to include uncovered files.

Wrong - Browser Mode spy on sealed export:

import * as math from './math';
import { vi } from 'vitest';

vi.spyOn(math, 'add').mockReturnValue(10);

Correct - use spy-enabled module mock:

import { vi } from 'vitest';

vi.mock(import('./math'), { spy: true });

Why: Native browser ESM namespace objects are sealed, so direct spies on exports fail in Browser Mode.

Known Issues Prevention

IssueRoot CauseSolution
Tests never exitWatch mode started in a non-interactive sessionUse vitest run
Coverage report misses untested filescoverage.include not configuredAdd explicit source globs
Browser Mode spy throws or does nothingvi.spyOn used on sealed ESM exportsUse vi.mock(import('./mod'), { spy: true })
Mocks leak between testsCleanup flags missingEnable restoreMocks / clearMocks / unstubEnvs
Multi-project config breaks after upgradeDeprecated workspace terminology or removed workspace-file patterns carried overSwitch to projects and defineProject
Worker or pool config stops workingOld maxThreads, maxForks, or poolOptions carried forwardMigrate to Vitest 4 worker settings such as maxWorkers
Project-specific config unexpectedly disappearsRoot config assumptions are not inherited into projectsUse extends: true, mergeConfig, or a shared base explicitly
AI-generated tests use wrong helpersJest patterns copied into VitestReplace with vi, Vitest imports, and Vitest matchers
Browser tests hangBlocking dialogs or wrong user-event utilitiesMock dialogs and use vitest/browser helpers
Fast pool causes strange native-module failuresthreads chosen for a suite that needs process isolationSwitch to forks or narrow thread usage

Bundled Resources

References

  • Mocking rules and hoisting → references/mocking-reference.md
  • Browser Mode providers and pitfalls → references/browser-mode-reference.md
  • Coverage and multi-project config → references/coverage-projects-reference.md
  • Pools, isolation, and persistent cache → references/pools-execution-reference.md
  • Reference index → references/README.md

Configuration Reference

vitest.config.ts

import { defineConfig, defineProject } from 'vitest/config';
import { playwright } from '@vitest/browser-playwright';

export default defineConfig({
  test: {
    projects: [
      defineProject({
        test: {
          name: 'unit',
          include: ['src/**/*.test.ts'],
          environment: 'node',
        },
      }),
      defineProject({
        test: {
          name: 'browser',
          include: ['src/**/*.browser.test.ts'],
          browser: {
            enabled: true,
            provider: playwright(),
            instances: [{ browser: 'chromium' }],
          },
        },
      }),
    ],
    coverage: {
      provider: 'v8',
      include: ['src/**/*.{ts,tsx}'],
    },
    restoreMocks: true,
    unstubEnvs: true,
    setupFiles: ['./test/setup.ts'],
  },
});

Key settings:

  • test.projects: Stable multi-project terminology; the rename started in Vitest 3.2, and projects do not automatically inherit every root config value, so shared settings should be factored into a reused base when needed
  • coverage.include: Required when uncovered source files must appear in the report
  • browser.provider: In Vitest 4, import the provider factory from the provider package, such as playwright()
  • restoreMocks / unstubEnvs: Prevent test pollution across files
  • setupFiles: Run shared test initialization such as MSW, globals, or polyfills before test files

Project Structure

my-app/
├── src/
│   ├── feature.ts
│   ├── feature.test.ts
│   └── feature.browser.test.ts
├── vitest.config.ts
├── vite.config.ts
└── package.json

Why this matters: Keeping Node and Browser Mode tests clearly separated makes provider setup, test selection, and troubleshooting much simpler.

Choose the right environment: Prefer jsdom for most component tests and lightweight DOM assertions. Use Browser Mode when native browser APIs, real layout/event behavior, or screenshot assertions matter.

Choose the right execution model: Prefer forks for stability and native-module compatibility, especially in mixed or infrastructure-heavy suites. Reach for threads only when you know the test environment is safe for worker-thread execution and the extra speed matters.

Common Patterns

Type-safe module mock pattern

import { beforeEach, describe, expect, it, vi } from 'vitest';
import { getUserName } from './get-user-name';
import * as api from './api';

vi.mock(import('./api'), () => ({
  fetchUser: vi.fn(),
}));

describe('getUserName', () => {
  beforeEach(() => {
    vi.mocked(api.fetchUser).mockReset();
  });

  it('returns the fetched user name', async () => {
    vi.mocked(api.fetchUser).mockResolvedValue({ id: '1', name: 'Ada' });

    await expect(getUserName('1')).resolves.toBe('Ada');
  });
});

Browser Mode interaction pattern

import { expect, test } from 'vitest';
import { page, userEvent } from 'vitest/browser';
import { render } from 'vitest-browser-react';
import { Counter } from './counter';

test('increments after click', async () => {
  render(<Counter />);

  await userEvent.click(page.getByRole('button', { name: /increment/i }));

  await expect.element(page.getByText('1')).toBeInTheDocument();
});

In-source testing pattern

export function sum(a: number, b: number) {
  return a + b;
}

if (import.meta.vitest) {
  const { it, expect } = import.meta.vitest;

  it('adds numbers', () => {
    expect(sum(1, 2)).toBe(3);
  });
}

Dependencies

Required

PackageVersionPurpose
vitest^4Test runner and assertion/mocking APIs
vite^6Shared Vite-powered module pipeline
node>=20Required runtime for Vitest 4

Optional

PackageVersionPurpose
@vitest/coverage-v8^4Fast, accurate coverage with AST remapping
@vitest/coverage-istanbul^4Istanbul coverage backend
@vitest/browser-playwright^4Playwright provider for Browser Mode
@vitest/browser-webdriverio^4WebdriverIO provider for Browser Mode
@vitest/browser-preview^4Preview provider for Browser Mode

Official Documentation

Troubleshooting

Agent run hangs forever

Symptoms: The test process never exits or Claude waits for additional file changes.

Solution:

vitest run

Browser Mode test cannot spy on export

Symptoms: vi.spyOn() throws, does nothing, or works in Node mode but fails in browser.

Solution:

vi.mock(import('./module'), { spy: true });

Coverage misses source files with no tests

Symptoms: The report only contains files touched by executed tests.

Solution:

coverage: {
  provider: 'v8',
  include: ['src/**/*.{ts,tsx}'],
}

Legacy worker or pool settings break after upgrade

Symptoms: Old maxThreads, maxForks, singleThread, singleFork, or poolOptions settings stop working after moving to Vitest 4.

Solution:

test: {
  maxWorkers: 4,
}

Why: Vitest 4 simplified worker configuration and removed several older pool-specific options.

Setup Checklist

Before using this skill, verify:

  • Node.js is >=20
  • vite is >=6
  • vitest.config.ts or vite.config.ts contains a test block
  • Agent/CI commands use vitest run
  • Coverage provider packages are installed if coverage is enabled
  • Browser provider packages are installed if Browser Mode is enabled

FAQ

What does the vitest-v4 skill do?

Vitest 4+ testing with Vite. Use when configuring vitest.config.ts, writing unit/integration/browser tests, implementing mocks with vi.fn/vi.spyOn/vi.mock, setting up V8 or Istanbul coverage, or migrating from Jest or older Vitest workspace setups. Triggers on vitest, vitest.config.ts, vi.mock, browser mode, vitest/browser, projects, setupFiles, and toMatchScreenshot.

How do I install vitest-v4?

Run npx skills add https://github.com/nodnarbnitram/claude-code-extensions --skill vitest-v4 in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/vitest-v4/ (personal) or .claude/skills/vitest-v4/ (project).

Which AI agents can use vitest-v4?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is vitest-v4 safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains vitest-v4?

It is published by nodnarbnitram in nodnarbnitram/claude-code-extensions. It has 62 recorded installs.

More from nodnarbnitram/claude-code-extensions

View all →

tauri-v2

nodnarbnitram/claude-code-extensions

Tauri v2+ cross-platform app development with Rust backend. Use when configuring tauri.conf.json, implementing Rust commands ([tauri::command]), setting up IPC patterns (invoke, emit, channels), configuring permissions/capabilities, troubleshooting build issues, or deploying desktop/mobile apps. Triggers on Tauri, src-tauri, invoke, emit, capabilities.json.

Backend & APIs8.1K installs

code-reviewer

nodnarbnitram/claude-code-extensions

Review code for best practices, security issues, and potential bugs. Use when reviewing code changes, checking PRs, analyzing code quality, or performing security audits.

ha-voice

nodnarbnitram/claude-code-extensions

Configure Home Assistant Assist voice control with pipelines, intents, wake words, and speech processing. Use when setting up voice control, creating custom intents, configuring TTS/STT, or building voice satellites. Activates on keywords: Assist, voice control, wake word, intent, sentence, TTS, STT, Piper, Whisper, Wyoming.

Media & Creative218 installs

esphome-config-helper

nodnarbnitram/claude-code-extensions

Open the skill to read its SKILL.md instructions.

136 installs

frigate-configurator

nodnarbnitram/claude-code-extensions

Open the skill to read its SKILL.md instructions.

117 installs

ha-energy

nodnarbnitram/claude-code-extensions

Open the skill to read its SKILL.md instructions.

104 installs

Popular testing & qa skills

View category →

tdd

mattpocock/skills

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Testing & QA1.2M installs

grilling

mattpocock/skills

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Testing & QA996.2K installs

migrate-to-shoehorn

mattpocock/skills

Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.

Testing & QA484.1K installs

run-train

lllllllama/rigorpilot-skills

Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.

Testing & QA337.8K installs

test-driven-development

obra/superpowers

Use when implementing any feature or bugfix, before writing implementation code

Testing & QA261.8K installs

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Testing & QA216.8K installs