テスト戦略
テストを書く意味・目的
テストを書くことは、ソフトウェア開発において非常に重要である。その主な目的と意義は以下の通り。
a) 品質保証
- バグの早期発見と修正
- 仕様との整合性の確認
- ユーザー体験の向上
b) 開発効率の向上
- リグレッションの防止
- リファクタリングの安全性確保
- 開発者の自信向上
c) ドキュメンテーション
- コードの使用方法や期待される動作の明確化
- チーム内でのコミュニケーション促進
d) 設計の改善
- テスタビリティの高いコード設計の促進
- コンポーネントの責務の明確化
バグが発生しやすい状況
a) コードの変更や機能追加時
- 既存の機能に影響を与える可能性
- 新旧コードの相互作用による予期せぬ動作
b) 異なる環境での動作時
- ブラウザの違いによる挙動の差異
- デバイスのスペックや画面サイズの違いによる問題
c) ユーザーの予期せぬ操作時
- 想定外の入力値や操作順序
- 高負荷時や低ネットワーク環境での使用
d) 外部APIとの連携時
- APIの仕様変更や障害
- データ形式の不一致
不正な状態を防ぐためのテスト
a) 入力値のバリデーション
- 必須項目のチェック
- 形式や範囲の検証
b) エラー処理とエッジケース
- 境界値テスト
- エラー時の適切なフィードバック
c) 状態管理の一貫性
- コンポーネント間の状態の整合性
- 非同期処理後の状態更新の検証
d) セキュリティ関連のチェック
- XSS攻撃の防止
- CSRF対策の確認
テストの種類
静的テスト
目的：コードの品質と一貫性を保つ
手法：
- TypeScriptの型チェック：型の不一致や潜在的なエラーを事前に検出
- ESLintによるコード品質チェック：コーディング規約の遵守、潜在的なバグの検出
- Prettierによるコードフォーマット：コードスタイルの統一
主なツール：
- TypeScript Compiler
- ESLint（カスタムルールの設定）
- Prettier
単体テスト
目的：個々のコンポーネントや関数の正確性を確認
対象：
- Reactコンポーネント
- ユーティリティ関数
- カスタムフック
テスト内容：
- プロップスの受け渡し
- イベントハンドリング
- 状態の更新
- 条件付きレンダリング
- ビジュアル（UI/UX）
主なツール：
- Jest
- React Testing Library
- @testing-library/react-hooks
- Storybook
結合テスト
目的：複数のコンポーネントやモジュール間の連携を確認
対象：
- 複数のコンポーネントで構成される機能
- コンテキストやReduxとの連携
- APIとの連携
テスト内容：
- データの流れ
- 状態の共有と更新
- エラー処理
- 非同期処理
- ビジュアル（UI/UX）
主なツール：
- React Testing Library
- MSW (Mock Service Worker)
- Storybook
E2Eテスト
目的：実際のユーザー体験に近い形で全体的な機能を検証
対象：
- 主要なユーザーフロー
- クリティカルな機能
- 複数ページにまたがる操作
テスト内容：
- サインインからサインアウトまでの一連の流れ
- 検索機能や絞り込み機能
- フォーム送信と結果の確認
主なツール：
- Cypress
- Playwright
テスト戦略モデル
アイスクリームコーン型
概要:
- E2Eテストに最も重点を置くモデル
- 上位のテスト（E2Eテスト、結合テスト）の比率が高い
- 下位のテスト（単体テスト、静的テスト）の比率が低い
特徴:
- ユーザー体験に近いテストを重視
- システム全体の動作確認に焦点を当てる
- 早期のフィードバックが難しい
- テストの実行時間が長くなりがち
適している状況:
- レガシーシステムの保守
- 小規模なプロジェクト
- 迅速なプロトタイピングが必要な場合
テストピラミッド型
概要:
- 下位のテスト（単体テスト、静的テスト）に重点を置くモデル
- 上位に行くほどテストの数が少なくなる
- 単体テストが最も多く、E2Eテストが最も少ない
特徴:
- 高速で頻繁なフィードバックが可能
- 下位レベルでの問題を早期に発見できる
- テストの保守が比較的容易
- コスト効率が良い
適している状況:
- 大規模で複雑なプロジェクト
- 継続的デリバリーを実践している開発チーム
- マイクロサービスアーキテクチャ
テスティングトロフィー型
概要:
- 静的テストに最も重点を置き、他のテストタイプもバランスよく配分するモデル
- テストピラミッドを進化させたモデル
特徴:
- 静的テストによる早期の問題発見
- 単体テストと結合テストのバランスが良い
- E2Eテストも適度に含まれる
- モダンな開発プラクティスに適合
適している状況:
- フロントエンド開発（特にReactやVueなどのコンポーネントベースのフレームワーク）
- アジャイル開発
- 品質と開発速度のバランスを重視するプロジェクト
理想のテスト戦略
- ロジックは基本的に hooks に切り出す
- hooks は基本的に単体テスト書く
静的テスト
- 全てのTypeScriptファイルに対して厳格な型チェックを適用
- ESLintルールセットをカスタマイズし、プロジェクト固有のルールを追加
- Prettierの設定をチーム内で統一し、コードスタイルの一貫性を確保
- CIでの自動チェックを実施し、問題がある場合はビルドを失敗させる
単体テスト
- 全てのReactコンポーネントに対して、最低限のレンダリングテストを実施
- ロジックを含むコンポーネントは、各条件分岐をカバーするテストを作成
- ユーティリティ関数は、入力値の範囲や特殊なケースを考慮したテストを実施
- カスタムフックは、異なる使用シナリオでのテストを行う
- モックやスタブを適切に使用し、外部依存を分離
- StorybookでコンポーネントのUIの確認を行う
結合テスト
- 主要な画面やフローに対して、複数のコンポーネントの連携をテスト
- Recoilやコンテキストを使用している場合、状態の更新と反映をテスト
- APIとの連携は、MSWを使用してモックレスポンスを返すテストを実施
- エラーケースや読み込み中の状態なども考慮したテストを作成
E2Eテスト
- サインインなど主要な機能の利用など、重要なフローをテスト
- 複数のデバイスサイズや主要なブラウザでのテストを実施
理想のテスト実施方針
-
新機能開発時：
- 機能仕様に基づいたテストケースを事前に作成
- TDD（テスト駆動開発）の適用を推奨
- 単体テストと結合テストを必須とし、機能の重要度に応じてE2Eテストも追加
- コードレビュー時にテストの十分性も確認
-
バグ修正時：
- バグを再現するテストケースを先に作成
- 修正後、そのテストが通ることを確認
- 関連する箇所の既存テストも確認し、必要に応じて追加や修正
-
リファクタリング時：
- リファクタリング前に全てのテストが通ることを確認
- リファクタリング後も全てのテストが通ることを再確認
- テストコード自体のリファクタリングも定期的に実施
-
CIでの自動テスト実行：
- プルリクエスト作成時に全てのテストを実行
- メインブランチへのマージ時にも全テストを実行
- テスト失敗時はマージをブロック
- 定期的（例：毎晩）にE2Eテストを実行し、環境の変化による影響を早期に検出
-
パフォーマンステスト：
- 重要な画面やコンポーネントに対して、定期的にパフォーマンス計測を実施
- Lighthouseなどのツールを使用し、スコアの推移を監視
-
アクセシビリティテスト：
- 開発中のコンポーネントに対して、aXeなどのツールを使用してチェック
- 定期的に全画面に対してアクセシビリティ監査を実施