CI での Vitest vs Jest: 速度、ESM、移行

著者 Kaveh Alemi·Latchkey

テストの実行時間はしばしば CI の最も長いステップです - Vitest と Jest は速度と ESM で大きく異なります。

どちらも JS/TS のテストを実行します。Vitest は Vite ネイティブで ESM ファースト、Jest は巨大なエコシステムを持つ定番の標準です。

Vitest vs Jest at a glance

CI では

Vitest は概して高速で、Jest の "Cannot use import statement" 失敗を引き起こす ESM transform の頭痛を回避します。Jest は大規模で成熟したスイートには安全な選択肢のままです。

• Static import statements are evaluated before your code runs, so the hoisting jest.mock() depends on cannot happen under ESM.
• require() of an ESM file with top-level await throws ERR_REQUIRE_ASYNC_MODULE.
• The jest object has to come from @jest/globals or import.meta.jest rather than being ambient.
• Jest documentation notes the underlying Node APIs it uses for this are themselves experimental.

# Jest, ESM mode
NODE_OPTIONS="$NODE_OPTIONS --experimental-vm-modules" npx jest

# ...plus transform: {} in config (or a transformer emitting ESM),
# ...plus extensionsToTreatAsEsm for .ts/.jsx,
# ...and jest.mock() no longer works:

const { charge } = await import('./payments.js');
jest.unstable_mockModule('./payments.js', () => ({ charge: jest.fn() }));

# Vitest, no flags, no mode
vi.mock('./payments.js', () => ({ charge: vi.fn() }));

どちらも OOM しうる

大きなスイートはどちらの runner でも CI ワーカーを OOM させます - いずれにせよワーカー数を制限し、メモリを適正化してください。

移行が見た目より安く済む理由

VitestはJest互換の expect とJest互換のモックユーティリティを意図的に実装しています。これにより移行の大部分は書き直しではなく機械的な作業になります。

• describe、it、test、beforeEach などは同じです。
• expect(...) のmatcherはJest互換なので、アサーションはほとんど変わりません。
• jest.fn() は vi.fn()、jest.spyOn() は vi.spyOn()、jest.mock() は vi.mock() になります。おおむね検索と置換です。
• スナップショットは形式がJest互換なので、既存のスナップショットファイルは通常そのまま使えます。
• Vitestの設定で globals: true にすれば describe/it/expect がアンビエントのまま残るので、初日にすべてのテストファイルへimportを追加する必要はありません。

速度について、正直なところ

Vitestは概して高速で、特にwatchモードではViteスタイルの依存グラフを通じて変更分だけを再実行します。コールドなマシンのCIでは差はベンチマークが示すより小さくなります。どちらも実時間の大きな割合を、アサーションではなくインストールとtransformに費やすからです。

• watchモードは差が最も明白で、開発者が毎日体感する場所です。
• どちらもCIマシン間のシャーディングに対応しているため、大規模では並列度が許す水準に両者が収束します。
• ts-jest を使っているなら、計測されたJestの遅さの一部は実行ごとの型チェックであって、runnerではありません。Jest自体のせいにする前に babel-jest と比較してください。

Jestに留まるべき場合

• コードベースがCommonJSで、今後もそのままである。移行の主な論拠が当てはまりません。
• カスタムのJest transformerや、Vitestに同等物のないJest固有のpluginに依存している。
• React Nativeを使っており、そこではJestのpresetが踏み固められた道である。
• スイートが大きく安定していて、誰も不満を言っていない。移行は実コストであり、その見返りは開発体験の改善で測られます。

移行を安全に進める

1. カスタムtransformer、Jestのplugin、Jestの内部に触れるものを棚卸しします。作業量が読めないのはここだけです。
2. VitestをJestと並べて追加し、globals: true を設定して既存のテストファイルを編集不要にします。
3. 1つのディレクトリを変換します。両方のスイートをCIで走らせ、合否の数だけでなく結果そのものを差分で比較します。
4. 変換したファイル全体で jest. を vi. に検索置換し、きれいに対応しない少数を直します。
5. スナップショットは意図的に再生成し、丸ごと受け入れるのではなく差分をレビューします。
6. 差分が空になり、スプリント1回分まるごと新しいrunnerでスイート全体が緑になってから、Jestを外します。

The switching cost is mostly in the parts nobody lists

• Assertions and mocks usually port mechanically when the target implements a compatible API; custom transformers and framework plugins do not.
• Snapshot formats differ between runners, so plan to regenerate and review rather than port.
• Run both suites in parallel in CI for a period and diff the results. A migration that changes which tests fail is not a migration, it is a regression you have not found yet.
• Coverage numbers move on a runner change even when the tests do not, because instrumentation differs. Re-baseline any coverage gate deliberately.

The verdict

新規プロジェクトや ESM 中心: Vitest。既存の大きな Jest スイート: ESM の痛みが移行を強いない限り Jest のまま。

よくある質問

関連ガイド