先に要点
- Vitest は ` Vite ベースの JavaScript / TypeScript テストランナー』。`Jest と非常に近い API』 を持ちつつ、`ESM 標準』 `TypeScript / JSX 直接実行』 `Vite 設定の流用』 で、Jest の `重い設定地獄』 を解消する。
- ` it / describe / expect / vi.fn() / vi.mock()』 など、Jest 経験者がほぼそのまま書ける API。`Jest からの移行コストは小さい』 のが普及の最大要因。
- 強みは 速度。ESM + Vite のキャッシュ機構で、`Jest より数倍速い』 体感が普通。さらに ` UI モード(ブラウザで結果可視化)』 `ブラウザモード(本物のブラウザで実行)』 も組み込み。
- 本命用途は ` Vite / Next.js / SvelteKit / Astro / Nuxt 系のモダンな TS プロジェクト』。Jest が標準だった頃の `CRA / 古めの Webpack 案件』 では Jest 続行で十分なケースもある。
Vitest ってよく聞くけど、Jest と何が違うの？ ESM のテストで Jest がエラー吐くのに困っている』 TypeScript の設定が複雑になりすぎた』 ── モダンな TS / ESM 環境で開発する人にとって、Vitest は事実上のテストランナーのデファクトです。
ざっくり言うと、Vitest は Vite の上に乗った、Jest 互換 API のテストランナー』</strong> です。Jest をそのまま置き換えられる感覚で書ける』 のに、ESM / TypeScript / JSX をネイティブで扱える』 Vite と設定を共有できる』 という、Jest が苦手としていた領域を一気に解消したのが急成長の理由です。
この記事では、2026 年 5 月時点の Vitest v3 系をベースに、仕組み・Jest との違い・移行手順・採用判断軸 を整理します。 仕様は活発に変化しているので、最終確認は 公式ドキュメント を見るのが安全です。
なぜ Vitest が必要になったか
`Jest で何が辛いのか』 から見ると、Vitest の存在意義が分かります。
①ESM / TypeScript の設定が複雑
Jest は CommonJS 前提 で生まれたため、`ESM プロジェクトでテストだけ CJS に変換』 のような設定が必要。`Babel / ts-jest / SWC』 の組み合わせで設定が長くなる。
② Vite と設定が二重化
` Vite の resolve / alias / plugin』 を Jest 側でも書き直す必要があった。`tsconfig.paths』 や `Vite alias』 の同期で消耗。
③ 速度
` 大規模プロジェクトで Jest が遅い』 体感。Vite の ` モジュールキャッシュ』 と並列実行が、テスト時間を大きく短縮する。
④ Vite エコシステムの統合
` Vite の `vite.config.ts』 をテストでも使える』 ことで、`コンポーネント開発 = テスト』 が同じ前提で動く。
Jest を捨てる』 のではなく、<strong> Jest の良い API を維持しつつ、Vite ベースで速度と互換性を改善する』 のが Vitest の発想です。
基本の書き方
最小例で雰囲気をつかみます。
// math.ts
export const add = (a: number, b: number) => a + b;
// math.test.ts
import { describe, it, expect } from 'vitest';
import { add } from './math';
describe('add', () => {
it('returns sum', () => {
expect(add(1, 2)).toBe(3);
});
it('handles negatives', () => {
expect(add(-1, 1)).toBe(0);
});
});
# 実行
npx vitest
# UI モード(ブラウザで結果を見る)
npx vitest --ui
# カバレッジ
npx vitest --coverage
Jest 互換 API
`describe』 `it』 `test』 `expect』 `beforeEach』 `afterAll』 など、Jest 経験者がそのまま書ける。` Jest からの移行コストが非常に小さい』。
設定ファイル
`vite.config.ts』 の `test』 セクションに書ける。`Vite と Vitest で同じ config を共有』 する設計が標準。
UI モード
`--ui』 で立ち上がる Web UI。`どのテストが失敗したか』 `差分の可視化』 `スナップショットの確認』 をブラウザで操作できる。
グローバル変数 / モック
`vi.fn()』 `vi.mock('モジュール名')』 `vi.spyOn』 など、Jest の `jest.fn / jest.mock』 と同じ感覚。`命名が `vi』 に変わるだけ』 で他はほぼそのまま。
`Jest を書ける人なら、ほぼ追加学習なしで Vitest が書ける』 のが体験を一言で表します。
Jest との比較
`Jest と Vitest、何が違う？』 を表で並べます。
| 軸 | Jest | Vitest |
|---|---|---|
| 登場時期 | 2014 | 2021 |
| ベース | CommonJS | ESM(Vite) |
| TypeScript / JSX | 外部設定が必要(ts-jest / babel) | ネイティブサポート |
| 速度 | 普通 | 速い(Vite のキャッシュ) |
| UI モード | ×(別ツール) | 標準(`--ui』) |
| ブラウザモード | × | 標準(本物のブラウザで実行) |
| watch モード | ○(やや遅い) | ◎(ESM のキャッシュ効果) |
| カバレッジ | 標準 | 標準(`@vitest/coverage-v8』) |
| エコシステム | 圧倒的に豊富 | 急成長中 |
| 主な選び所 | 既存 Jest 案件 / Webpack ベース | 新規 / Vite 系 / ESM 重視 |
要点は 新規プロジェクトはほぼ無条件で Vitest、既存 Jest は無理に移行しない』</strong> です。Jest で困っていなければそのまま』、`Jest の設定が辛くなった』 段階で Vitest 移行を検討、というのが現実的な流れです。
Jest から Vitest への移行
`Jest で動いている既存テストを Vitest に移す』 手順を整理します。
`数百テストのプロジェクトでも、半日程度で移行できる』 のが現実的な感触です。
ブラウザモード — 本物のブラウザで実行
Vitest の特徴のひとつが ` ブラウザモード(Browser Mode)』 です。
jsdom との違い
Jest / Vitest 標準では `jsdom』(Node 上の DOM エミュレータ)で実行する。` 実ブラウザの挙動とは微妙に違う』。ブラウザモードは Playwright / WebdriverIO ベースで 本物の Chromium / Firefox / Safari で実行。
利点
` 本物の `IntersectionObserver』 `ResizeObserver』 `Web Animation API』 が動く』。jsdom で `動くはずが動かない』 系のテストで真価を発揮。
使い分け
` 普通の単体テストは jsdom / Node』、`ブラウザ依存の挙動が混ざるテストはブラウザモード』 という棲み分け。`遅さと信頼性のトレードオフ』 を意識して選ぶ。
E2E との関係
` Vitest ブラウザモードは `単体テストをブラウザで』 という位置づけ、Playwright / Cypress は `画面操作シナリオの E2E』 と棲み分け。両方使うチームも多い。
単体テストとは別世界』 だった ブラウザ実行』 が、Vitest なら同じ設定の上に乗る、というのが革新的な部分です。
採用判断のチェックリスト
`Vitest を選ぶか Jest 続行か』 の判断材料を整理します。
向いている(Vitest)
① 新規 Vite / Next.js / SvelteKit / Astro プロジェクト、② ESM ネイティブで書く案件、③ Jest 設定で消耗している既存プロジェクト、④ Storybook + テストの統合を狙う案件。
Jest を選ぶ理由が残る
① 既存の大規模 Jest テストが大量にあり移行コストが高い、② Jest 専用プラグインに強く依存、③ CRA / 古い Webpack ベース。
既存 Jest からの移行コスト
` jest → vi』 の置換と config 作成で 数時間〜半日。`スナップショットも互換』 で大半そのまま動く。
`迷ったら新規 Vitest、既存は段階移行』 が現実的な指針です。
どこで詰まりやすいか
便利な反面、現場で踏みやすい注意点もあります。
①ESM 専用ライブラリの罠
` ESM-only のライブラリ』 をモック化したいときに、`vi.mock』 の書き方が Jest と微妙に異なる場面がある。`pnpm の workspace』 と組み合わせると特に複雑化。
② vi.mock のホイスト
` vi.mock』 もホイストされるが、`変数キャプチャ』 の挙動が Jest と少し違う。`vi.hoisted』 を使うと明示的に巻き上げを制御できる。
③ 並列実行とグローバル状態
` テストファイルは並列実行』 がデフォルト。`グローバル状態に依存するテスト』 を書くと、別ファイル間の干渉でフレイクが起きやすい。
④ カバレッジツール
`@vitest/coverage-v8』 と `@vitest/coverage-istanbul』 の2系統がある。`v8』 が速いが `istanbul』 のほうが既存資産との互換性が高い。
`Jest からの移行で本当に困るところは vi.mock 周辺』 が、現場で繰り返し見るパターンです。
AI 時代の Vitest
AI 連携の文脈で Vitest の価値も上がっています。
速いフィードバックループ
AI でコードを書く → `vitest --watch』 で即フィードバック。`Jest よりさらに短い』 反復時間が、`AI が書いたコードを試して改善する』 速度を底上げする。
AI 生成テストの実行
` AI が生成したテストコード』 をプロジェクトに貼って即実行。`設定の壁』 が低いので、AI 出力をそのまま試しやすい。
CI のコスト圧縮
AI 駆動で `CI 実行頻度』 が増える時代、`テストが速い』 は `Vercel の請求』 や CI 課金にダイレクトに効く。
プロンプトに含めやすい
` describe / it / expect』 という共通言語なので、AI に `Vitest で書いて』 と頼むだけで、`Jest と同じ』 様式の出力が返ってくる。
`AI 時代の TypeScript 開発の足回り』 として、Vitest は不可欠なツールに位置づけられています。
Vitest に関するよくある質問
Q. Jest と Vitest、どちらを学ぶべきですか？
A. 新規プロジェクトに参加する人は Vitest を中心に学ぶ』のが2026年現在の最適解です。API は Jest 互換なので、`Jest の解説記事』 もほぼ Vitest にそのまま当てはまります。両方知っている必要はありません。
Q. Vitest は React Native でも使えますか？
A. ` 限定的に可能ですが、推奨はされていません』。React Native は Metro バンドラと Jest がデファクトの組み合わせで、Vitest の良さ(Vite との統合)が活きづらいです。Expo 経由でも Jest が標準です。
Q. Storybook と Vitest はどう連携できますか？
A. Storybook の Stories をテストとして実行できる』</strong>のが Vitest と Storybook の連携の真価です。storybook test』 や `@storybook/test』 を通して、Story を Vitest のテストケースとして扱えます。
Q. Mock がうまく書けません。
A. vi.mock の場所と書き方』 がカギです。<strong> ファイルトップで vi.mock を呼ぶ』のが基本で、変数キャプチャが必要なら vi.hoisted』 を使います。Jest と完全互換ではない部分』 の代表で、Vitest のドキュメントを必ず参照する価値があります。
Q. SSR / Edge 環境のテストはどうしますか？
A. environment』 設定で node』 / jsdom』 / happy-dom』 / edge-runtime』 を選べます。<strong> Edge ランタイムのコード(Cloudflare Workers や Vercel Edge)もテスト可能です。
Q. Vitest の学習コストは？
A. Jest 経験者なら数時間で書き始められる』</strong>レベルです。API はほぼ同じ』 設定が短い』 ので、難所は vi.mock の細部』 と `ESM の挙動』 くらいです。
Q. Vitest と Playwright の関係は？
A. Vitest = 単体テスト / 統合テスト』</strong>、<strong> Playwright = E2E テスト(ブラウザ操作シナリオ)』です。両方を `単体は Vitest、E2E は Playwright』 のように併用するのが2026年の標準的なテスト戦略です。