ナレッジワーク、フロントエンドのテスト基盤をJestからVitestへ。ESM互換性の壁を越えるため足掛け3日で移行したが、CI上の実行時間は約1.5倍に

ナレッジワークのフロントエンドはNext.jsを採用しており、テストフレームワークにはNext.jsと相性の良いJestを採用していた。関数単位のテストやUIコンポーネントのテストを書く分には問題なかったが、それより上層、たとえばページ単位になると、たちまちESM互換性の問題を踏んでしまう。JestはCJSを前提として動作しており、ESM前提のモジュールを動かすのに一手間も二手間もかかるからだ。そのため、テストを書こうにも腰の重い状態が続いていた。そんな中、ある機能でページ単位のテストを重点的に書く必要性が生まれた。ちょうどVitestのv1.0.0がリリースされたこともあり、移行するには絶好のタイミングだとして、この機会にVitestへ移行することになった。

移行は基本的に公式ドキュメントの手順どおりに進めたが、プロジェクト固有の事情で公式に書かれていない部分もあった。

• 依存の更新: jest、@types/jest、jest-environment-jsdom、@storybook/jestなどを削除し、vitest、@vitejs/plugin-react-swc、jsdom、vite-tsconfig-paths、@next/env、@storybook/testを追加
• plugin-reactの代わりにplugin-react-swcを使い、Babel部分のトランスパイルを高速化
• next/jestをやめたため、@next/envで環境変数を自前でセット
• vite-tsconfig-pathsでインポートのエイリアス設定をtsconfig.jsonから読み込む
• happy-domは一部の動作に不具合があったため見送り、jsdomを採用
• testTransformModeを、Vitest 0.33→0.34で起きたパフォーマンス劣化の対策として設定
• jsdomで未実装のメソッドなどはセットアップファイルでモック

同時期にリリースされたStorybook 7.6で@storybook/testがVitestを使うように変更されたため、@storybook/jestからの移行も合わせて行った。

調査やレビューを含め、足掛け3日ほどで移行が完了した。

• 直接の依存の数は増えたが、pnpm-lock.ymlの差分は682 additions / 1,109 deletionsで、だいぶ身軽になった
• ローカル実行はJestとVitestで体感できるほどの差がなかった
• CI（GitHub Actions）上での実行は約1.5倍の時間がかかるようになった。原因はわかっていない

それでも、CIのボトルネックはVRT（Visual Regression Test）の方であることや、CIの最適化の余地がまだあることを勘案し、全体としてはVitestに乗っておいた方が良いという結論に至った。これまでテストを書けなかった領域への道が開かれたとしている。