Handism's Tech Blog
学習ガイド一覧へ戻る

Webフロントエンドテスト入門

テストピラミッドなどのテスト戦略の基本概念から、Vitest + React Testing Libraryを用いたコンポーネントテスト、さらにPlaywrightによるE2Eテストまで、モダンなフロントエンドにおけるテスト手法を体系的に学びます。

学習をスタートする

ロードマップ

1

テストの基礎概念とテストピラミッド

モダンなWebアプリケーション開発において、コードが正しく動くことを保証し、機能追加やリファクタリングを迅速に行うためには自動テストが欠かせません。フロントエンド開発でも、UIの複雑化や多様な状態変化に伴い、テストの重要性が高まっています。 第1章では、フロントエンドにおけるテストの重要性、主要な3つのテストレイヤー、そして効果的なテスト戦略のモデルである「テストピラミッド」と「テストトロフィー」について学びます。 1. なぜフロントエンドでテストが必要なのか？ 「コードを書いて、ブラウザで動作確認すれば十分ではないか？」と考えるかもしれません。しかし、手動の動作確認にはいくつかの限界があります： * リグレッション（デグレード）の検知漏れ：ある箇所を修正した結果、全く関係のない別のページや機能が壊れてしまう問題。手動で全ページを毎回チェックするのは不可能です。 * リファクタリングへの恐怖：コードをきれいに整理したいが、「動いているものを壊したくない」ために改善を躊躇してしまう。 * 動作仕様のドキュメント化：「テストコード」は常に最新の状態で動く仕様書（ドキュメント）として機能します。 自動テストが整備されていると、コマンドを1つ実行するだけで数秒から数分で全体の健康状態が確認できるため、開発の生産性が劇的に向上します。 2. フロントエンドテストの3つのレイヤー フロントエンドにおけるテストは、主に以下の3つの異なるレベルに分かれています。 2-1. 単体テスト (Unit Test) ユーティリティ関数や独立した計算ロジック、カスタムフック単体を検証します。外部へのアクセス（APIなど）はすべてダミー（モック）に置き換えます。 * 例: 日付フォーマット関数、フォームバリデーションロジックの検証 2-2. 結合テスト (Integration Test) 複数のコンポーネントが組み合わさった時の挙動や、ユーザーの入力（クリックや文字入力）に対するDOMの更新を検証します。 * 例: カートへの追加ボタンを押したときに、カート内のアイテム数が「1」増え、合計金額が正しく計算されるかの検証 2-3. E2E テスト (End-to-End Test) 実際のブラウザをバックグラウンドで起動し、データベースや本物のAPIサーバーと接続して、ユーザーが実際に操作するのと同様の挙動（ログイン、決済など）を検証します。 * 例: ログイン画面で正しい情報を入力し、ダッシュボードへ遷移してデータが表示される一連の流れの検証 3. テストピラミッドとテストトロフィー テストをどのように組み合わせるべきかについては、2つの代表的な設計思想があります。 3-1. テストピラミッド (Testing Pyramid) 古くからソフトウェアテストで提唱されているモデルで、「実行速度が早くコストの低い単体テストを土台として最も多く書き、実行が遅く高コストなE2Eテストは少なく抑える」 という構成です。 3-2. テストトロフィー (Testing Trophy) フロントエンドの権威 Kent C. Dodds 氏などが提唱する、モダンフロントエンドにより適したモデルです。 フロントエンドはUIコンポーネントの集合体であり、単体でロジックをテストするよりも、「コンポーネントの組み合わせ（結合テスト）を最も手厚くテストするべき」 という考え方です。 コストと信頼性のトレードオフ テストレベルごとの性質は以下のように対照的です： テストの種類 実行スピード 壊れにくさ（保守性） 本物らしさ（信頼性） コスト 単体テスト 🚀 1ミリ秒未満 🟢 高（影響範囲が狭い） 🔴 低（ブラウザの挙動とは異なる） 💸 安い 結合テスト 🟡 数十ミリ秒 🟢 高（詳細の実装変更に強い） 🟡 中（DOMを模倣して実行） 💸 中程度 E2Eテスト 🐌 数秒〜数十秒 🔴 低（ネットワークや実行環境で崩れやすい） 🟢 最高（本物のブラウザと本物の環境） 💸 高い 4. フロントエンドでのテスト戦略の立て方 効果的なテストスイートを構築するための戦略は以下の通りです： 1. 静的チェックの徹底 * TypeScript の型チェックや ESLint、Prettier を活用し、構文エラーや型不整合といった最も単純なバグをコードを書いている段階で自動排除します（トロフィーの土台）。 2. 結合テスト（コンポーネントテスト）を主軸にする * UIパーツが意図通りに相互作用するかどうかを、Vitest や React Testing Library などのツールで最も多く記述します。これにより、コードの内部設計（リファクタリング）を変えてもテストが壊れず、ユーザーから見た挙動が変わらない限りテストが通り続けます。 3. 極めて重要なユーザー体験のみをE2Eテストで保護する * 「ログイン」「新規登録」「チェックアウト（決済）」といった、ビジネス上絶対に失敗してはならないコアルートのみを Playwright などでカバーします。 まとめ * 手動確認から自動テストへの移行が、デグレードを防ぎチームの生産性を最大化するための鍵。 * フロントエンド開発では、ロジックのみの単体テストに偏りすぎず、UIとイベントハンドリングを検証する 「結合テスト（コンポーネントテスト）」を最も重視する（テストトロフィーモデル）。 * プロダクトの重要パス（決済やログイン）は、信頼性の高い E2Eテスト でカバーする。 次のチャプターでは、テストトロフィーの中心である Vitest と React Testing Library を使用したコンポーネントテストの書き方 を具体的に学びます！

2

Vitest と React Testing Library によるコンポーネントテスト

前章で学んだ「テストトロフィー」モデルにおいて、最も重要とされるのが コンポーネント結合テスト です。Reactにおけるデファクトスタンダードである Vitest と React Testing Library (RTL) を用いることで、ユーザーに近い視点でUIの振る舞いを検証できます。 第2章では、これらのツールを使った具体的なテストの書き方と、アクセシビリティを意識した要素の検索方法について学びます。 1. ツールスタックの紹介 1-1. Vitest とは？ Vite をベースにした次世代の非常に高速なテストランナーです。従来の Jest と互換性のある API を持ちつつ、ESモジュールや TypeScript を標準でサポートし、Vite のビルド設定と連動するためモダンフロントエンド開発で圧倒的な人気を博しています。 1-2. React Testing Library (RTL) 「ソフトウェアがユーザーによってどのように使用されるか（振る舞い）」をテストすることに焦点を当てたライブラリです。 * 従来のテスト（Enzymeなど）: state やコンポーネントの内部構造（実装詳細）をテストするため、コードを書き直すとテストが崩れやすかった。 * React Testing Library: HTMLとして出力されたDOM構造やアクセシビリティ情報をテストするため、リファクタリングに極めて強い。 「実装の詳細ではなく、ユーザーが見るものと操作するものに基づいてテストする」ことが重要です。 2. 初めてのコンポーネントテスト：Counterコンポーネント シンプルな「カウントアップボタン」を例に、テストの実装方法を見ていきます。 対象コンポーネント テストコード 3. 適切な要素の取得方法（Query Priority） RTLで要素を見つけるためのクエリには優先順位があります。これは、テストをアクセシブルなものにし、ユーザーに近い方法でテストするためです。 クエリの使い分け例： getByRole を使うことで、「画面上に正しくボタンがレンダリングされており、スクリーンリーダーなどの補助技術でも検知可能であるか」を同時に検証することができます。 4. 非同期処理とAPI通信のテスト コンポーネントがAPIからデータをフェッチして後から描画される場合、同期的な getByText では要素がまだ存在しないためエラーになります。この場合は findBy... や waitFor を使用します。 非同期コンポーネント 非同期テストの書き方 まとめ * Vitest：Vite統合の極めて高速なテスト実行エンジン。 * React Testing Library (RTL)：「ユーザーのようにテストする」ためのライブラリ。内部実装の書き換えに強く、リファクタリングが楽になる。 * getByRole を最優先で使う：アクセシビリティを保証し、画面の要素を安全に取得するためのベストプラクティス。 * 非同期要素には findBy... や waitFor を使う：ローディングやAPIのフェッチ後の結果をテストする際は、待機処理が必要。 次のチャプターでは、より広範囲で実際のシステム全体の動作を確認する Playwright を用いた E2E テスト について学びます！

3

Playwright による E2E テストと CI 連携

前章までで、ロジックの単体テストやコンポーネントテストについて学びました。しかし、コンポーネントが単体で動作していても、「ブラウザ全体でのルーティングが崩れている」「本物のAPIサーバーとの連携が切れている」といったシステム全体での致命的な欠陥は防ぎきれません。 これを防ぐのが、本物のブラウザ環境でシナリオテストを実行する E2E（End-to-End）テスト です。 第3章では、モダンE2Eテストツールである Playwright の基本操作と、継続的インテグレーション（CI）パイプラインとの連携について学びます。 1. Playwright とは？ Playwright は Microsoft が開発する、モダンWebアプリケーション向けの高速かつ信頼性の高いE2Eテストフレームワークです。 * マルチブラウザ対応：Chromium (Chrome/Edge), WebKit (Safari), Firefox の3大ブラウザエンジンをネイティブサポートし、並列でテストを実行できます。 * 自動待機 (Auto-waiting)：クリックや入力を実行する前に、要素が画面に表示され、クリック可能になるのを自動的に待機します。これにより、「テストが時々落ちる（Flaky Test）」というE2Eテスト最大の課題を解決します。 * 強力なデバッグツール：テスト実行過程をビデオや画像、ネットワークログとして保存する Trace Viewer などの便利な機能が標準装備されています。 2. Playwright テストの書き方 以下は、ログイン画面を開いてユーザー名とパスワードを入力し、ログイン成功後にマイページに遷移できているかを検証する典型的なE2Eテストコードです。 3. Playwright のコア機能 3-1. ロケーター（Locator）とアサーション Playwright は、操作対象の要素を定義する Locator オブジェクトを介して操作を行います。アサーションは expect(locator).toHaveText() などの形で記述します。 3-2. 自動待機（Auto-waiting） Playwright は、操作（click, fill, check など）を実行する直前に、対象の要素に対して以下の条件を自動的にチェックし、満たすまで（デフォルト最大30秒）待機します。 * 要素が DOM に存在しているか * 画面に表示されているか（CSSで非表示になっていないか） * アニメーションが停止しているか * 他の要素に遮られていないか * 有効状態（Disabledでない）か これにより、page.waitForTimeout(3000) のような「不安定なスリープ処理」を書く必要が一切なくなります。 4. GitHub Actions による CI パイプライン連携 作成したテストコードは、ローカル環境だけで動かすのではなく、「コードが GitHub にプッシュされたとき」 や 「プルリクエストが作成されたとき」 にクラウド上で自動実行させることで最大の効果を発揮します。 以下は、GitHub Actions を使用して、コード変更の度に Playwright のテストを走らせ、失敗した場合はマージできないように保護するためのCIワークフロー定義です。 ワークフロー設定例 まとめ * E2Eテスト は、本物のブラウザを用いてアプリ全体の連携を検証する、最上位の品質保証手段。 * Playwright は、マルチブラウザ対応や自動待機（Auto-waiting）により、高い開発効率と安定したテスト環境を提供する。 * テストを GitHub Actions 等の CI/CD に組み込む ことで、破壊的なバグが本番環境（ユーザー）に届くのを未然に防ぎ、リファクタリングを継続して行える環境を整える。 これで「Webフロントエンドテスト入門」コースの全チャプターは完了です！ 静的チェック（TypeScript, ESLint）、結合テスト（Vitest & RTL）、そしてE2Eテスト（Playwright）の3本柱を適切に組み合わせ、バグのない強固なフロントエンドアプリケーションを構築していきましょう。

4

MSWによるAPIモックとビジュアルリグレッションテスト (VRT)

コンポーネントテストやE2Eテストを実行する際、本番や開発用のAPIサーバーに直接依存すると、「通信速度の低下」「データの変更によるテストの不安定化（フラッキーテスト）」「サーバー停止時のテスト失敗」などの問題が発生します。 また、UIの見た目の正確性（レイアウト崩れやCSSの適用漏れ）を通常のコードベースのテスト（expect(...).toBeVisible() など）だけで網羅するのは極めて困難です。 第4章では、これらの問題を解決する MSW (Mock Service Worker) によるAPIモックと、視覚的バグを自動検知する VRT (Visual Regression Testing) の仕組みを学びます。 1. MSW (Mock Service Worker) によるAPIモック 従来のテストモック（jest.mock や global.fetch = jest.fn() など）は、JavaScript実行環境内の関数やグローバルオブジェクトを書き換える「モンキーパッチ」と呼ばれる手法でした。 これに対して MSW は、ブラウザの標準機能である Service Worker を使用して、ネットワークの物理層レベルでHTTPリクエストをインターセプト（横取り） します。 MSWの動作フロー MSWのメリット * コードの変更が不要: アプリケーションコード内のAPIリクエスト送信処理を一切モック用に変更することなく、テストやローカル開発を実行できます。 * モック定義の共通化: テスト（Node.js環境）とローカル開発環境（ブラウザ環境）で、同一のモックコードを再利用できます。 * 例外のシミュレーションが容易: 500サーバーエラー、ネットワーク切断、タイムアウトなどの異常系テストが簡単に書けます。 モックハンドラーの実装例 2. VRT (Visual Regression Testing / ビジュアル回帰テスト) コードに変更を加えた際、DOMの構造自体は変わらなくても、「マージンがズレた」「色が意図せず変更された」「モバイル幅で文字が重なって読めなくなった」 といった表示の崩れ（デグレーション）が発生することがあります。 これを防ぐのが VRT (ビジュアル回帰テスト) です。 VRTの仕組み 1. 基準画像の作成 (Golden Image / Baseline): バグがない状態のコンポーネントまたはページのスクリーンショットを撮影し、Gitなどにコミットしておきます。 2. 比較画像の撮影 (Target Image): コード修正後のテスト実行時に、同じ画面のスクリーンショットを再び撮影します。 3. ピクセル差分（Diff）の検出: 特殊なライブラリを用いて2つの画像をピクセル単位で重ね合わせ、変更箇所をハイライト（通常はマゼンタや赤で色付け）した差分画像を生成します。差分が許容値（スレッショルド）を超えるとテストが失敗します。 VRT のワークフローとツール VRTは、単体でスクリプトを書くよりも、既存のフロントエンドエコシステムと統合して運用するのが一般的です。 Playwright を使ったVRTの例 ブラウザテストツール Playwright には、標準でスクリーンショットのピクセル比較機能が備わっています。 Storybook × Reg-suit (または Chromatic) コンポーネントカタログである Storybook の各ストーリー（コンポーネント単体の表示パターン）を巡回してスクリーンショットを自動撮影し、OSSツールの reg-suit や、Storybook公式のマネージドサービス Chromatic などを用いてCI上でビジュアルテストを実行する手法が、現在の大規模Web開発で広く採用されています。 [!TIP] フォントや日付のゆらぎ対策 VRTを導入すると、フォントレンダリングの微妙なOS差（MacとLinux CIなど）や、動的に変化するシステム日時（2026-06-22 など）の表示によってテストが失敗（偽陽性）しやすくなります。 これを防ぐために、「日付を固定モックにする」「CSSでカーソル点滅を停止する」「Playwrightの mask オプションで動的エリアを黒塗りにする」 などのノウハウが必要です。 まとめ * MSW は、Service Worker を用いることで、テストコードにモンキーパッチを当てることなく、ネットワークレベルでAPIをモック化する。 * MSWのモック定義は、Vitestなどのユニットテスト、PlaywrightなどのE2Eテスト、さらにはローカル開発用の環境まで幅広く共通利用できる。 * VRT (ビジュアル回帰テスト) は、修正前後でページやコンポーネントのスクリーンショットをピクセル単位で比較し、レイアウト崩れを自動的に検知する。 * Playwright や Storybook (reg-suit / Chromatic) と組み合わせることで、開発効率と視覚的品質保証を劇的に向上できる。

5

継続的インテグレーション（CI）でのテスト自動化

テストを書くだけでは十分ではありません。テストが「開発プロセスの一部」として機能し、壊れたコードが本番環境へデプロイされるのを未然に防ぐ仕組みが必要です。 第5章では、GitHub ActionsなどのCIツールを使い、プルリクエストの作成時に自動でフロントエンドテストを実行する環境づくりについて学びます。 1. 継続的インテグレーション (CI) とは？ 継続的インテグレーション（CI）とは、開発者がコードの変更を共有リポジトリに頻繁に統合し、その都度 「自動ビルド」と「自動テスト」 を実行してエラーを早期に発見するプラクティスです。 フロントエンド開発において、CIパイプラインの主な目的は以下の通りです。 1. コードがTypeScriptの型検査をパスするか確認する 2. ESLint/Prettierなどによる静的チェックやフォーマットを検証する 3. Unitテスト・E2Eテストがすべて正常に動作するか確認する 2. GitHub Actions による基本的なワークフロー GitHub Actions を利用すると、.github/workflows/test.yml という定義ファイルを置くだけで簡単にテストを自動化できます。 高速化のためのポイント * npm ci の使用: npm install より高速で、package-lock.json と完全に一致する依存関係を厳格にインストールします。 * 依存関係のキャッシュ (cache: 'npm'): node_modules の生成元であるキャッシュを再利用することで、セットアップ時間を数十秒から数分短縮できます。 3. CIでのE2Eテストとスクリーンショットの管理 PlaywrightなどのE2EテストをCI上で動かす場合、ブラウザを実行するための重い環境が必要になります。 E2Eテストが失敗した際、ブラウザのスクリーンショットや動画、トレースビューアーデータ（Trace Archive）をアーティファクトとして保存・アップロードする設定 を行うことで、ローカル環境との差異（フォントの違い、画面サイズ、読み込みラグなど）によるデバッグを容易にします。 まとめ * 継続的インテグレーション (CI) により、プルリクエスト単位で型検査や単体・統合テストを強制し、バグの混入を極限まで減らせる。 * GitHub Actions などの環境で キャッシュ戦略 や並列テストを取り入れることで、CIのフィードバックループを高速化できる。 * E2EテストのCI実行時は、失敗時の スクリーンショット・動画の保存設定 がトラブルシューティングで決定的に重要となる。