アンチパターンを避けるためのベストプラクティス（依存の選び方ガイドライン）
ここまで「モック・スタブ・フェイクのアンチパターン」を見てきました。では、実務で どう選び分ければよいか を整理した「ガイドライン」をまとめます。
依存の選び方ガイドライン
1. ユニットテスト（業務ロジック）
- 目的: ビジネスルールが正しく動くかを確認
- 依存: 外部要因は完全に排除
- 選び方:
- スタブ → 固定値を返す（正常系・異常系を両方用意）
- モック → 呼び出し検証（「このメソッドが呼ばれたか」確認）
👉 ポイント: 「ロジックの正しさ」を保証するために、外部依存は必ずモック／スタブ化。
2. 統合テスト（層の結合確認）
- 目的: コントローラ層＋サービス層の結合を確認
- 依存: 簡易的な代替を利用
- 選び方:
- フェイク → メモリDBや簡易APIを用意して結合部分を確認
👉 ポイント: 「結合の流れ」を確認するために、フェイクで本物に近い挙動を再現。
3. エンドツーエンドテスト（システム全体）
- 目的: 実際の環境でユーザー操作を再現
- 依存: 本物の外部サービスやDBを利用
- 選び方:
- 実際の依存 → 本番に近い環境で動作確認
👉 ポイント: 「現実の障害や例外処理」が正しくレスポンスに変換されるかを確認。
まとめ表
| テスト層 | 目的 | 依存の扱い | 適切な選択 |
|---|---|---|---|
| ユニットテスト | 業務ロジック検証 | 外部依存を排除 | モック / スタブ |
| 統合テスト | 層の結合確認 | 簡易依存を利用 | フェイク |
| E2Eテスト | システム全体確認 | 本物の依存を利用 | 実際の環境 |
ベストプラクティスのポイント
- モックは呼び出し検証に限定
- スタブは正常系・異常系両方用意
- フェイクは簡易的に留める（本番の複製はNG）
- テスト層ごとに依存の種類を明確に分ける
✅ このガイドラインを守ることで、テストが「効率的で壊れにくい」ものになります。