モック・スタブ・フェイクを使ったテスト戦略の組み合わせ例
ここまでで「モック・スタブ・フェイク」の違いを整理しました。次は ユニットテスト・統合テスト・E2Eテスト でどう使い分けるかを具体的に見ていきましょう。
テスト層ごとの使い分け
1. ユニットテスト（Unit Test）
- 目的: 業務ロジック（ユースケース層やドメインモデル）の正しさを確認
- 使うもの: スタブ or モック
- 理由: 外部依存を完全に排除して、ロジックだけを検証する
👉 例:
UserRepositoryをスタブ化して「必ずユーザーを返す」ようにするDatabase.save()が呼ばれたかをモックで検証する
2. 統合テスト（Integration Test）
- 目的: コントローラ層＋サービス層の結合を確認
- 使うもの: フェイク
- 理由: 実際の依存を模した簡易実装を使うことで、結合部分をテストできる
👉 例:
- メモリ上で動く
FakeDatabaseを使って「保存→取得」の流れを確認 - 外部APIをフェイク化して「固定レスポンスを返す簡易実装」を利用
3. エンドツーエンドテスト（E2E Test）
- 目的: システム全体の動作確認（UI → コントローラ → サービス → インフラ）
- 使うもの: 本物の依存（DBや外部API）
- 理由: 実際の環境でユーザー操作を再現する必要がある
👉 例:
- 実際の外部APIにアクセスして「ユーザー取得」動作を確認
- DBにテスト用データを投入して「保存→取得→レスポンス返却」を確認
まとめ表
| テスト層 | 目的 | 依存の扱い | 適切なテクニック |
|---|---|---|---|
| ユニットテスト | 業務ロジック検証 | 外部依存を排除 | モック / スタブ |
| 統合テスト | 層の結合確認 | 簡易依存を利用 | フェイク |
| E2Eテスト | システム全体確認 | 本物の依存を利用 | 実際の環境 |
実務のコツ
- ユニットテスト: 細かい条件分岐や早期リターンを徹底的に検証
- 統合テスト: フェイクを使って「結合部分の流れ」を確認
- E2Eテスト: 実際の環境で「例外処理が正しくレスポンスに変換されるか」を確認
✅ この組み合わせで「テスト効率」と「信頼性」を両立できます。