Jestは2014年にFacebook（現Meta）のChristoph Nakazawaらが社内ツールとして開発を始め、翌2015年にオープンソースで公開したJavaScriptテストフレームワークである。React公式の推奨ランナーとして急速に普及し、テストランナー、アサーション、モック、カバレッジ計測を単一パッケージに統合する「オールインワン」志向で従来のMocha+Chai+Sinon型構成と一線を画した。本稿ではJestの成り立ち、スナップショットテストなど独自機能、設定方法、ESMやTypeScriptとの統合について順に整理する。
この記事の目次
- Jest誕生の経緯とアーキテクチャ
- スナップショットとモックの使い方
- 設定・TypeScript・ESM対応
- Vitestや他フレームワークとの比較
- まとめ
Jest誕生の経緯とアーキテクチャ
FacebookのフロントエンドはJavaScriptで書かれた数千モジュール規模に達しており、Jasmineベースの既存テスト基盤では実行速度と並列性に限界が見えていた。Christoph NakazawaとSebastian McKenzieらはこの課題を解決するため、テストファイルごとに独立したNode.jsワーカーを起ち上げて並列実行し、グローバル状態の汚染を防ぐ設計を採用した。2015年にOSS化されると、Reactとともに利用例が広がり、2017年頃には世界のJSプロジェクトで最も使われるテストランナーの一つとなった。
アーキテクチャ上の柱は、ワーカープール並列実行、jest-haste-mapによる高速ファイル探索、自動モック、スナップショットの四点である。Babel/SWCトランスフォーマでTypeScriptやJSXを透過的に処理し、jsdom環境を内蔵してブラウザAPIをNode.js上で擬似的に提供する。これによりブラウザ用のコンポーネントテストもヘッドレスブラウザを起ち上げずに実行できる構造が標準となった。
スナップショットとモックの使い方
Jestを象徴する機能がスナップショットテストである。expect(component).toMatchSnapshot()と書くと初回実行時に出力結果を__snapshots__ディレクトリへ保存し、二回目以降はその内容と比較する。UIコンポーネントやAPIレスポンスの構造変化を機械的に検知でき、差分が出た場合はjest --updateSnapshotで意図的に更新する運用となる。ただし長文のスナップショットは差分レビューが難しいため、toMatchInlineSnapshot()で対象を絞る手法が推奨されてきた。
モック機構もJestの強みで、jest.mock('./module')を宣言するだけでモジュール全体を自動的に置き換える。jest.fn()でスパイ関数を生成し、mockResolvedValueやmockImplementationで挙動を細かく定義できる。タイマー制御ではjest.useFakeTimers()がsetTimeoutやPromiseマイクロタスクまでを擬似化し、非同期コードの境界を明確に検査できるため、レスポンシブUIや状態機械のテストで威力を発揮する。
設定・TypeScript・ESM対応
Jestの設定はjest.config.jsまたはpackage.jsonのjestフィールドで宣言する。testEnvironmentにjsdomかnodeを選び、transformでBabel、ts-jest、SWCのいずれかを指定する。TypeScriptプロジェクトではts-jestを採用する例が長らく主流だったが、2022年以降は@swc/jestへ移行することでビルドを伴わない高速実行を選ぶチームが増えている。testMatchやcoveragePathIgnorePatternsで対象範囲を絞れば、モノレポでも整然と管理できる。
ESM対応は段階的に進められてきた。バージョン28以降は--experimental-vm-modulesフラグでネイティブESMを扱えるが、import.meta.urlやトップレベルawaitなどに制約が残るため、CommonJS互換のトランスフォームと併用するケースが多い。並列度は--maxWorkersで制御でき、CI環境ではコア数の半分程度に絞ることでメモリ枯渇を避けるのが定石である。
Vitestや他フレームワークとの比較
Jestと頻繁に比較されるのが2021年登場のVitestである。VitestはViteのトランスフォーム機構をそのまま流用するため、ESMとTypeScriptを設定なしで扱え、ホットモジュールリプレース連携によるウォッチ性能が高い。一方でJestはエコシステムが厚く、React Testing LibraryやNext.js、React Nativeとの統合が成熟しているため、既存資産が大きいプロジェクトではJestを維持する判断も合理的である。
Karma+Jasmine構成と比べると、Jestはブラウザを介さない分テストが軽量で並列実行に向くが、実ブラウザでのレンダリング差異を検証する目的にはPlaywrightやCypressなどのE2Eツールが別途必要となる。JestはあくまでユニットテストとIntegrationの中間レイヤを担う道具と位置づけ、用途に応じてVitestやE2Eツールと組み合わせる構成設計が、現代のフロントエンド品質管理の基本となっている。
まとめ
JestはFacebookが社内の規模課題を解くために設計したテストランナーが、コミュニティの支持を得て事実上の標準へ育った好例である。スナップショットや自動モックといった独自機能、jsdom同梱の手軽さ、そして広いエコシステムが強みだが、ESMやVite前提のプロジェクトでは後発のVitestと比較検討し、自プロジェクトの構成に合うランナーを選ぶ姿勢が望ましい。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント