先に要点
- 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 のテストランナー です。 「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 を捨てる」 のではなく、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 は無理に移行しない です。 「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 をテストとして実行できるのが Vitest と Storybook の連携の真価です。「storybook test」 や 「@storybook/test」 を通して、Story を Vitest のテストケースとして扱えます。
Q. Mock がうまく書けません。
A. 「vi.mock の場所と書き方」 がカギです。ファイルトップで vi.mock を呼ぶのが基本で、変数キャプチャが必要なら 「vi.hoisted」 を使います。「Jest と完全互換ではない部分」 の代表で、Vitest のドキュメントを必ず参照する価値があります。
Q. SSR / Edge 環境のテストはどうしますか？
A. 「environment」 設定で 「node」 / 「jsdom」 / 「happy-dom」 / 「edge-runtime」 を選べます。` Edge ランタイムのコード(Cloudflare Workers や Vercel Edge)もテスト可能です。
Q. Vitest の学習コストは？
A. Jest 経験者なら数時間で書き始められるレベルです。「API はほぼ同じ」 「設定が短い」 ので、難所は 「vi.mock の細部」 と 「ESM の挙動」 くらいです。
Q. Vitest と Playwright の関係は？
A. Vitest = 単体テスト / 統合テスト、Playwright = E2E テスト(ブラウザ操作シナリオ)です。両方を 「単体は Vitest、E2E は Playwright」 のように併用するのが2026年の標準的なテスト戦略です。