クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

フロントエンドのテストを Jest から Vitest へ移行し始めた話

はじめに

こんにちは。クラウドソーシングサービス「クラウドワークス」（ crowdworks.jp ）でエンジニアをしている倉野です。2024年10月に株式会社クラウドワークスに入社し、主にフロントエンド開発を担当しています。

今回は、フロントエンドのユニットテストツールを Jest から Vitest へ移行し始めた経緯と、その過程で得られた学びについてお話しします。

なぜ移行を考えたのか？

これまで、処理速度の速さやWeb開発ビルドツール Vite との互換性から、Vitest への移行を漠然と考えていました。しかし、移行コストや他の業務との兼ね合いで、なかなか踏み出せずにいました。

そんな中、今年の3月、フロントエンドで使用しているフレームワーク Vue.js のユーティリティ関数集 VueUse の 大きなアップデート（Breaking Change） がありました。具体的には「CommonJS（CJS）ビルドが廃止され、ES Modules（ESM）のみでのビルドとなる」という変更です。

このアップデートに対応するため、現在の Jest で ESM 対応を進めるよりも、テストツール自体を Vitest に変更する方が将来的にも良いのではないかと考えました。他のフロントエンドエンジニアとも相談した結果、「やってみよう！」という結論に至ったのです。

移行のメリットとデメリット

移行を検討するにあたり、主なメリットとデメリットを洗い出しました。

メリット

  • ESM のネイティブサポート
    • ESM ベースのパッケージやプロジェクトにおいて、特別な設定なしでスムーズに動作します。
  • テスト実行速度の向上
    • 高速なテスト実行とリソース効率の改善が期待できます。
  • TypeScript サポートの強化
    • TypeScript との相性が良く、設定がより簡単になります。

デメリット

  • 歴史の浅さ
    • Jest に比べて歴史が浅いため、実績や安定性、情報量、プラグイン、拡張機能の数で劣る可能性があります。
  • 既存コードの書き換えコスト
    • 既存のテストコードを Vitest 用に書き換える手間がかかります。Jest の機能に強く依存しているコードがある場合、さらにコストが増大する可能性があります。
  • チームメンバーの学習コスト
    • 新しいツールに慣れるまでの学習時間が必要となります。

この中で最も懸念されたのは「既存コードの書き換え」でした。Jest で書かれたテストファイルが約200ファイルもあり、これらすべてを書き換える時間をどう捻出するかが最大の課題だったのです。一方で、学習コストについては、Vitest が Jest API の大部分と互換性があるため、検証の結果、スムーズに移行できそうだと判断しました。

どうすればスムーズに移行できるか？

当初、私はテストファイルの移行を一気に進めることを想定していました。しかし、他のメンバーから 「ファイルの数も多く、他の開発案件との兼ね合いもあるので、しばらく Jest と Vitest を共存させ、段階的に移行していくのはどうか」 というアドバイスをもらいました。

このアドバイスはまさに目から鱗でした。たしかに、両ツールの共存環境さえ構築してしまえば、新規に作成するテストは Vitest で書けますし、既存の Jest テストも業務状況に合わせて段階的かつ安全に移行を進めることができます。この方針であれば、ボトルネックだった「既存コードの書き換え」のハードルが大きく下がると判断し、段階的移行を進めることにしました。

段階的移行の具体的な進め方

Vitest と Jest を共存させ、段階的に移行を進めるための具体的なステップは以下の通りです。

  • Vitest 実行環境の構築 まず、プロジェクト内にVitestが動作する環境をセットアップします。

  • Jest テストファイル一覧の取得 現在 Jest で書かれているテストファイルの一覧を grep などのコマンドで取得します。

  • Jest 適用ファイルリストの作成 取得したファイルリストを JavaScript の配列として別途ファイルにまとめます。

// jestFiles.js
// Jestを適用させるtestファイルの一覧 
module.exports = [ 
  "/src/test/***.test.ts", 
  "/src/test/****.test.ts",
];
  • Jest 設定ファイルの修正 Jest の config ファイルで上記の JavaScript ファイルを読み込み、testMatch に配列を渡します。これにより、指定されたファイルのみが Jest で実行されるようになります
// jest.config.js
const jestFiles = require('./jestFiles');

module.exports = {
    // 省略
    // The glob patterns Jest uses to detect test files
      testMatch: ['!**/config.test.ts', ...jestFiles],
};
  • Vitest 設定ファイルの修正 Vitest の config ファイルで、同様にファイル一覧の JavaScript ファイルを読み込み、exclude（除外ファイル）に配列を渡します。これにより、Vitestでは指定されたファイルがテスト対象から外れます。

この方法によって、ファイル単位での移行管理が可能になり、業務の状況に合わせて空き時間に少しずつ移行を進められるようになりました。また、アップデートしたいパッケージ（今回の場合は VueUse ）を使用しているテストを優先的に Vitest へ移行することで、パッケージのアップデートにも支障なく対応できています。

おわりに

テストツールの移行のような環境改善業務は、規模が大きくなりがちでリソースもかかるため、「やりたくてもできない」というケースが多々あります。しかし、今回のようにスコープを小さく区切り、段階的に進めることで、日々の業務状況に合わせて行うことができ、移行のハードルを大きく下げられることを学びました。

もちろん、すべての改善業務がこの方法に当てはまるわけではありません。しかし、自分の業務やプロダクトに合わせた最適な改善方法を、これからも模索し続けていきたいと思います。

We're hiring!

株式会社クラウドワークスでは、エンジニアメンバーを募集しています！

herp.careers

© 2016 CrowdWorks, Inc., All rights reserved.