VitestとJestを比較 — JavaScriptテストはVitestに移行すべき？【2026年版】

Jestは長年JavaScriptのテストのデファクトスタンダードだったんだけど、最近Vitestが急速に普及してきたんだよ。特にViteを使ったプロジェクトでは、Vitestの方が自然な選択になってきたんだ。

VitestはViteをベースにしたテストフレームワークで、Jestと互換性のあるAPIを持ってるんだよ。つまりJestで書いたテストのほとんどがほぼそのままVitestでも動くんだ。「JestのVite版」ってイメージが近いかもしれないね。

全然違うよ。VitestはViteのHMRの仕組みを使って、変更があったファイルだけを再実行するんだ。JestもJITキャッシュがあるけど、Vitestはesbuildベースのトランスパイルが速くて、ウォッチモードの体感速度は明らかに速いよ。大規模なテストスイートで差がはっきり出るんだ。

Vitestの方がシンプルに感じる人が多いよ。Jestは `jest.config.js` で `transform` や `moduleNameMapper` をゴリゴリ書く必要があることが多いんだ。VitestはViteの設定（`vite.config.ts`）をそのまま使えるから、Viteプロジェクトなら設定ファイルがほぼ不要なんだよね。

これがVitestの大きな強みなんだ。JestでTypeScriptを使うには `ts-jest` や `babel-jest` などの変換ツールを別途設定する必要があったんだよ。VitestはesbuildがTypeScriptをネイティブに処理するから、追加設定なしでそのまま動くんだ。型チェックは別途 `tsc` で行う設計になってるよ。

そうなんだよ。Jestはデフォルトでcommonjs（`require`）で動いてて、ESModuleを使おうとすると色々と設定が必要で大変だったんだ。VitestはESModuleがデフォルトで、Viteと同じモジュール解決を使うから、現代のESModuleパッケージでも詰まることがほとんどないんだよ。

API自体はほぼ同じだよ。`vi.mock()` が `jest.mock()` に対応してて、`vi.spyOn()` が `jest.spyOn()` に対応してるんだ。細かいところでは、Vitestの `vi.fn()` はJestの `jest.fn()` とほぼ同じ動きをするよ。Jestから移行するときもモック周りはほとんど書き直しが要らないんだよね。

Jestはデフォルトで `istanbul`（`@jest/coverage`）を使うんだ。VitestはV8（Node.jsのビルトインカバレッジ）と `istanbul` の両方を選べるよ。V8は設定不要で速い代わりに精度が少し低め、`istanbul` は精度が高いけど少し遅いんだ。`@vitest/coverage-v8` か `@vitest/coverage-istanbul` を入れて選べるよ。

プロジェクトによるんだけど、ViteベースのReact（Vite + React）やVue、Svelteのプロジェクトなら、Vitestの方がセットアップが断然ラクだよ。VitestはViteのプラグインをそのまま使えるから、JSXやVue SFCの変換設定を別途やらなくていいんだ。Testing LibraryもVitestで普通に使えるよ。

ビルドキャッシュがない初回のCIだとVitestの優位はやや小さくなるんだけど、それでも並列実行の効率はVitestが良くて、GitHub ActionsなどのCIでも速い傾向があるよ。特にテスト数が多いプロジェクトで差が出るんだ。Vitestは `--reporter=github-actions` があってCIの出力もきれいだよ。

比較的スムーズにできるよ。`jest.config.js` を `vitest.config.ts` に書き直して、`jest` の import を `vitest` に変えて（`describe`・`it`・`expect` はグローバルのままでもいい）、パッケージを入れ替えるだけで動くケースが多いんだ。大変なのは `jest.mock()` のファクトリ関数で独自の巻き上げ挙動に依存してるケースとか、カスタムトランスフォームを大量に書いてる場合だよ。

あるよ。Node.jsのバックエンドだけのプロジェクトでViteを使ってない場合は、Jestでも全然問題ないんだ。あとJestは長年使われてきてエコシステムが成熟してるから、特殊なカスタムマッチャーやプラグインが必要な場合はJestの方が選択肢が多いことがあるよ。企業の大規模レガシープロジェクトでは移行コストが見合わない場合もあるんだよね。

「Viteを使ってる or 使う予定のプロジェクト」「TypeScriptをゴリゴリ書いてる」「ESModuleのパッケージでJestの設定に詰まってる」という人はVitestに移行する価値が大きいよ。逆にJestで困ってない・ViteをつかってないNode.jsプロジェクトはそのままJestでいいんだよね。

Vitestのシェアが急拡大してて、新規プロジェクトではVitestを選ぶチームが増えてるよ。あとNode.js 22以降でビルトインのテストランナー（`node:test`）も使えるようになってきたんだ。軽量なバックエンドプロジェクトなら依存なしでテストできる時代になってきたよ。ただ、JestもまだMetaがメンテしてて現役だから、どちらが「勝ち」というわけじゃなくて、プロジェクトの性質で選ぶのが正解だよ。