Vitest vs Jest — 2025年版 JavaScript テストフレームワーク徹底比較

1. 結論

Vite ベースのプロジェクトなら Vitest を選ぶのが最適解です。 既存の大規模プロジェクトで Jest 資産が豊富にある場合は、無理に移行せず Jest を継続するのが現実的です。新規プロジェクトであれば、速度・DX（開発者体験）の面から Vitest を第一候補にすることをおすすめします。

---

2. 比較表

---

3. それぞれの強み

Vitest の強み

• 圧倒的な速度: Vite の HMR パイプラインを活用し、変更ファイルのみを高速に再実行します。大規模プロジェクトほど差が顕著です。
• ESM ファースト: import / export をネイティブに扱えるため、ESM 移行済みのコードベースでハック的な設定が不要です。
• TypeScript がゼロコンフィグ: esbuild による型ストリップが内蔵されており、ts-jest のような追加パッケージが要りません。
• Vite 設定との統合: vite.config.ts に test ブロックを追加するだけで済み、エイリアスやプラグインを二重管理する必要がありません。
• インラインテスト: ソースファイル内にテストを書ける独自機能があり、ユーティリティ関数のコロケーションに便利です。
• ブラウザモード: Playwright や WebDriverIO と連携し、実際のブラウザ上でテストを実行できます。

Jest の強み

• 圧倒的な実績と情報量: 10年以上の歴史があり、Stack Overflow・ブログ記事・書籍の情報が桁違いに豊富です。
• 巨大なエコシステム: jest-extended、jest-dom、jest-image-snapshot など、サードパーティマッチャーやプラグインが充実しています。
• フレームワーク公式サポート: Create React App、Angular CLI、NestJS など多くのフレームワークがデフォルトで Jest を採用しています。
• 安定性: メジャーバージョン間の破壊的変更が少なく、長期運用プロジェクトで安心感があります。
• --shard による CI 分散: 大規模 CI で複数マシンにテストを分散する仕組みが成熟しています（※ Vitest にも同機能あり）。

---

4. コード例で比較

題材: 非同期関数 fetchUser のテスト

まず、テスト対象のコードです。

// src/fetchUser.ts
export interface User {
  id: number;
  name: string;
}

export async function fetchUser(id: number): Promise<User> {
  const res = await fetch(`https://api.example.com/users/${id}`);
  if (!res.ok) throw new Error(`User ${id} not found`);
  return res.json();
}

---

Vitest で書いた場合

// src/__tests__/fetchUser.test.ts
import { describe, it, expect, vi, beforeEach } from 'vitest';
import { fetchUser } from '../fetchUser';

describe('fetchUser', () => {
  beforeEach(() => {
    vi.restoreAllMocks();
  });

  it('ユーザーを正常に取得できる', async () => {
    const mockUser = { id: 1, name: 'Taro' };

    // グローバル fetch をモック
    vi.stubGlobal('fetch', vi.fn().mockResolvedValue({
      ok: true,
      json: () => Promise.resolve(mockUser),
    }));

    const user = await fetchUser(1);

    expect(user).toEqual(mockUser);
    expect(fetch).toHaveBeenCalledWith('https://api.example.com/users/1');
  });

  it('404 の場合はエラーを投げる', async () => {
    vi.stubGlobal('fetch', vi.fn().mockResolvedValue({
      ok: false,
      status: 404,
    }));

    await expect(fetchUser(999)).rejects.toThrow('User 999 not found');
  });
});

実行コマンド:

npx vitest run
# Watch モード
npx vitest

---

Jest で書いた場合

// src/__tests__/fetchUser.test.ts
import { fetchUser } from '../fetchUser';

describe('fetchUser', () => {
  beforeEach(() => {
    jest.restoreAllMocks();
  });

  it('ユーザーを正常に取得できる', async () => {
    const mockUser = { id: 1, name: 'Taro' };

    // グローバル fetch をモック
    jest.spyOn(global, 'fetch').mockResolvedValue({
      ok: true,
      json: () => Promise.resolve(mockUser),
    } as Response);

    const user = await fetchUser(1);

    expect(user).toEqual(mockUser);
    expect(global.fetch).toHaveBeenCalledWith('https://api.example.com/users/1');
  });

  it('404 の場合はエラーを投げる', async () => {
    jest.spyOn(global, 'fetch').mockResolvedValue({
      ok: false,
      status: 404,
    } as Response);

    await expect(fetchUser(999)).rejects.toThrow('User 999 not found');
  });
});

実行コマンド:

npx jest
# Watch モード
npx jest --watch

---

コード比較のポイント

ご覧のとおり、テストコード自体はほぼ同じです。jest → vi に置き換えるだけで動くケースが大半であり、移行コストの低さが Vitest の大きな魅力です。

---

5. どちらを選ぶべきか — ユースケース別ガイド

✅ Vitest を選ぶべきケース

✅ Jest を選ぶべきケース

🔄 どちらでもよいケース

• React（Next.js 以外）の新規プロジェクト → Vitest 推奨（ただし Jest でも問題なし）
• Next.js → 公式が @next/jest を提供しているため Jest が安定。ただし Vitest 対応も進んでおり、どちらも選択可能

---

6. まとめ

Jest  = 安定・実績・情報量のデファクト標準
Vitest = 速度・DX・モダン設計の次世代テストランナー

Vitest は Jest の API を意図的に踏襲して設計されているため、「Jest の正統進化版」 と捉えるのが最も正確です。既存プロジェクトで Jest が問題なく動いているなら急いで移行する必要はありません。しかし、新規プロジェクトや Vite エコシステムを採用しているなら、Vitest を選ばない理由を探す方が難しいでしょう。

どちらを選んでも「テストを書く」という本質は変わりません。大切なのはフレームワーク選定に時間をかけすぎず、テストを書き続けることです。