VitestがJestを追い越した——「10倍高速・ESM完全対応・Vite統合」で次世代テストの標準になった理由

Jestは「遅い」——その根本的な理由

長年フロントエンドテストの標準だったJestが、2025年後半から急速にシェアを失いつつある。State of JS 2025の調査では、新規プロジェクトでのVitest採用率がJestを初めて上回った。

Jestが遅い理由は設計にある。Jestは2014年に登場し、CommonJS（require/module.exports）を前提とした設計だ。現代のTypeScript + ESM（import/export）環境では、Jestはトランスパイル処理を挟む必要があり、これがボトルネックになっている。また、ウォームアップなしに実行されるため、ファイル数が増えるほど起動オーバーヘッドが積み重なる。

Vitestが解決した3つの問題

① ESM・TypeScriptをネイティブで扱える

VitestはViteのトランスフォームパイプラインをそのまま使う。つまり、vite.config.ts にすでに書いているTypeScript・JSX・パスエイリアスの設定が、テスト環境でもそのまま動く。設定の二重管理が不要になる。

② ウォームアップ後の再実行が驚異的に速い

Vitestはモジュールをキャッシュする。ファイルを変更してから再テスト実行までの時間が、Jestと比べて平均5〜10倍高速という計測結果が複数の大規模プロジェクトから報告されている。特に「ウォッチモード（変更を監視して自動再実行）」での体験が圧倒的に改善される。

③ Viteの設定をそのまま使い回せる

ほとんどのReact・Vue・Svelte プロジェクトはすでにViteをバンドラーとして使っている。Vitestはvite.config.tsを読み込んで動作するため、モックの設定・環境変数・パスエイリアスを一切書き直さずにテストを書き始められる。

Jest → Vitest 移行の実際の手順

既存のJestプロジェクトからの移行コストは、多くの場合1日以内に収まる。以下が基本的な手順だ。

Step 1：パッケージ差し替え

npm uninstall jest ts-jest @types/jest babel-jest
npm install -D vitest @vitest/ui jsdom

Step 2：vite.config.ts にテスト設定を追加

import { defineConfig } from 'vite'
export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
  },
})

Step 3：テストファイルのimport修正

globals: true設定を有効にすれば、describe/it/expectのimportはJestと同様に不要のまま動く。ただしjest.fn()はvi.fn()に、jest.mock()はvi.mock()に書き換えが必要だ。一括置換で対応できる量感。

Step 4：package.jsonのscript更新

"test": "vitest",
"test:ui": "vitest --ui",
"coverage": "vitest run --coverage"

Vitest UIという「見えるテスト」体験

Vitestには公式のUIダッシュボードが用意されている（@vitest/ui）。ブラウザで各テストの通過/失敗をリアルタイムに確認でき、テスト結果のスナップショットも視覚的に比較できる。Jestでは外部ツールが必要だった機能が、標準で揃っている。

Reactコンポーネントテストは Testing Library と組み合わせる

UIコンポーネントのテストは、従来どおり @testing-library/react との組み合わせが推奨だ。VitestはJestと互換性の高いAPIを持つため、既存のrender()・screen.getByText()などのコードはほぼそのまま流用できる。

まとめ

Vitestへの移行は「設定を書き直す手間」より「テストが速くなる恩恵」の方がはるかに大きい。TypeScript + Viteの組み合わせを使っているプロジェクトなら、1〜2時間の作業でほぼ完結する。Jestのサポートサイクルが落ち着きつつある今、新規プロジェクトではVitest一択、既存プロジェクトも次のリファクタリング時に移行を検討するタイミングが来ている。