Zenn
📘

『フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識』をまとめてみた

2025/02/06に公開
frontend
Test
idea

はじめに

はじめまして。最近はフロントエンドを主に担当する弱弱エンジニアです。
フロントエンドエンジニアを対象に、「テスト」の基本知識と具体的な実践手法を解説した書籍で「フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識」というのがあり、とても有益だったので、軽くポイントとなる箇所をピックアップし自身のメモとして残そうと思います。

なぜこの本を?

  • 今まで

    • バックエンドのテストをほんの少し書いたことがある
    • だけどフロントのテストがわからないテストひよっこ状態
    • ただフロントエンド側もテストを考えた方が良いという近年の流れで読むようになった

  • 対象読者

    • フロントエンドの実装をしたことがない方
    • テストコードを書いたことがない方
    • DBまで含めたE2Eを書いたことがない方

→内容は初心者向き。フロントエンドテストを広く浅く学べる内容
ただ要所要所はある程度の知識を求められたり調べながら読んだりもした

各章のメモ

第1章　テストの目的と障壁

  • テストを書く目的

    • 事業の信頼のため
    • 健全なコードを維持するため
    • 実装品質に自信を持つため
    • 円滑なコラボレーションのため
    • リグレッションを防ぐため

  • テストを書く障壁

    • テストを書く習慣がなく、どのように書けばよいかわからない
    • テストを書いている時間があるなら、機能を追加したい
    • メンバーのスキルがまばらで、保守運用に自信が持てない

前例をコミットする若しくは既存のテストコード真似して書くなどで、テストに不慣れなメンバーでも、前例を参考にある程度のテストが書けるようになる

第2章　テスト手法とテスト戦略

  • テストの範囲
    1. ライブラリが提供する関数
    2. ロジックを担う関数
    3. UIを表現する関数
    4. Web APIクライアント
    5. APIサーバー
    6. DBサーバー

フロントエンドの自動テストを書くとき、この 1〜6のうち「どこからどこまでの範囲をカバーしたテストであるか」を意識する必要がある

  • Webフロントエンド開発におけるテストの範囲（テストレベル）は、概ね次の 4つに分類

    • 静的解析
      • TypeScriptや ESLintによる静的解析です。一つ一つのモジュール内部検証だけでなく、 2と3の間、 3と4の間、というように「隣接するモジュール間連携の不整合」に対して検証
    • 単体テスト
      • 2のみ、 3のみ、というように「モジュール単体が提供する機能」に着目したテスト
    • 結合テスト
      • 1〜4まで、 2〜3までというように「モジュールをつなげることで提供できる機能」に着目したテスト
    • E2Eテスト
      • 1〜6を通し、ヘッドレスブラウザ ＋ UIオートメーションで実施するテストです。最も広範囲な結合テストともいえるもので、アプリケーション稼働状況に忠実なテスト

  • テストの目的

    • テストは目的によって「テストタイプ」に分類
      • 機能テスト（インタラクションテスト）
        • 開発対象の機能に不具合がないかを検証するのが「機能テスト」
      • 非機能テスト（アクセシビリティテスト）
        • 非機能テストのうち、心身特性に隔てのない製品を提供できているかという検証が「アクセシビリティテスト」
      • リグレッションテスト
        • 特定時点から、前後の差分を検出して想定外の不具合が発生していないかを検証するテストが「リグレッションテスト」

  • テスト戦略モデル

    • アイスクリームコーン型
    • テストピラミッド型
    • テスティングトロフィー型

  • アイスクリームコーン型

    • 戦略モデルのアンチパターンとして参照されるモデル図
    • 運用コストが高く、E2Eテストは実行時間が長く、不安定

  • テストピラミッド型

    • ユニットテストを最も多く記載し、統合テスト（APIテストやコンポーネントテスト）を適度に実施。またE2Eテストは抑える
    • メリットとして
      ユニットテストが多いので、バグを早期に発見しやすい。コンポーネントの連携もチェックできる。

  • テスティングトロフィー型

    • 統合テストに比重を置く
    • E2Eテストも適度に行う
    • メリット
      • 実際のユーザー操作に近いテストが多いので、UIやコンポーネントの不具合を検出しやすい。
      • 統合テストを増やすことで、コンポーネント間の連携ミスを防げる
      • E2Eテストも適度に行うため、全体の動作も確認できる

第3章　はじめの単体テスト

テスティングフレームワークに「 Jest」を使用

test("add: 1 + 2 は 3", () => {
    expect(add(1, 2).toBe(3))
})

【アサーション】:
「検証値が期待通りである」という検証を行う文。マッチャーで構成されている
expect(検証値).toBe(期待値)
【マッチャー】:
expect関数に続けて記述するもの
toBe(期待値)、toEqual(期待値)など他にもある

第4章　モック

  • モックとは

    • モック（テスト用の仮想モジュール）の作成

  • モックを使用する目的

    • ネットワークの影響を受けずにテスト可能

第5章　UIコンポーネントテスト

  • UIコンポーネントテストとは、以下のUIコンポーネントの基本機能をテストする
    • データを表示すること
    • ユーザー操作を伝播すること
    • 関連するAPIにつなぐこと
    • データを動的に書き換えること

「@testing-library/react」という Testing Libraryを使用。
UI コンポーネントをテストするためのライブラリ群のことで、React Testing Library が有名

test('renders App component', () => {
    render(<App />); 
    expect(screen.getByText(Hello World:')).toBeInTheDocument(); 
});

第6章　カバレッジレポートの読み方

  • カバレッジレポートとは
    • 「テスト実行によって対象のコードがどのくらいの範囲が実行されたか」を計測し、出力されたレポート
      • Stmts（命令網羅率）
        • 実行されたコードのステートメント（命令文）の割合
      • Branch（分岐網羅率）
        • 条件分岐（if/else など）のすべての分岐が実行されたか
      • Funcs（関数網羅率）
        • 関数が呼び出された割合
      • Lines（行網羅率）
        • 実行されたコードの行数の割合

カバレッジレポートの目的
テストの抜け漏れを発見できる
どの部分のコードが十分にテストされていないかが分かる

→カバレッジが低い場合、新たにテストを追加の検討材料として使用できる
ただ、注意点としては「カバレッジの数値は高いからといって品質が高いテストであるとは限らない」

第7章　Webアプリケーション結合テスト

  • Next.js や React 特有の結合テストについて解説

    • React の Context API
      • Context API は、アプリケーション全体で共有するデータ（例: ユーザー情報やテーマ）を管理する仕組み
    • Next.js Router を織り交ぜた結合テスト

  • MSW

    • MSW（Mock Service Worker） は、APIリクエストをモック化するためのライブラリ
    • 実際のバックエンドサーバーにアクセスせず、Service Worker を利用して ブラウザやNode.js環境でHTTPリクエストをインターセプトできる
    • 外部APIやバックエンドの開発が完了していなくてもフロントエンドの開発やテストが可能

第8章　UIコンポーネントエクスプローラー

  • UI コンポーネントエクスプローラーとは
    • デザイナーやプロダクトオーナーとも共有ができるコラボレーションツール
    • 開発補助ツールやテストツールとしての役割をになっている
    • 本書籍ではstorybookを使用してUIコンポーネントテストを実施

第9章　ビジュアルリグレッションテスト

  • VRT(ビジュアルリグレッションテスト)とは
    • アプリケーションの外観の変化を自動検出するリグレッションテストの手法
    • VRTの主な目的は、コードやUIの変更が既存の画面レイアウトやデザインに対して予期しない変更を加えていないかを検証
    • 本書籍ではreg-suit + Storycapを使用
      • reg-suit は画像の差分検出を行う CLI
      • Storycapは自動スクリーンショット生成ツール

第10章　E2E テスト

APIやブラウザ等、実際にユーザーが使用するのと同じ環境下でも正常に動作するかをチェックするテスト。ブラウザ固有のAPIを使用したり、画面を跨ぐ機能テストに向いている
本書籍ではPlaywright（プレイライト）を使用。Microsoft社が開発したテスト自動化フレームワークのことで、WebアプリのE2E（End to End）テストに対応しており、テストコードを記述することでブラウザ操作を自動化できる。
さまざまな環境でテストできるメリットもある
Google Chrome、Microsoft Edge、Safariなど

所感

初心者にとっては広く浅い内容が掲載されている教科書のような立ち位置
今回の書籍はReactやNextでの紹介であったが、Vueが案件で使用されていたとしても活用できる書籍
どこまで実践するかはチームやプロダクトによって異なると思うので、取捨選択して取り入れてみると良いかもしれない。

Discussion