クリーンアーキテクチャを強化するテスト戦略
早期リターン・例外処理・レイヤード設計を組み合わせたコードは、テスト設計を意識するとさらに強力になります。ここでは ユニットテスト・統合テスト・エンドツーエンドテスト（E2E） の役割分担を整理します。
テスト戦略の3層構造
1. ユニットテスト（Unit Test）
- 対象: ユースケース層やドメインロジック（ビジネスルール）
- 目的: 業務ロジックが正しく動くかを確認
- 特徴: 外部依存（DBやAPI）はモック化してテスト
- 例:
GetUserProfileUseCase.execute("validId")→ 正しいプロフィールを返すGetUserProfileUseCase.execute("invalidId")→UserNotFoundExceptionを投げる
👉 早期リターンは「条件不一致のテストケース」を簡単に書ける。
👉 例外処理は「異常系をモックで再現」できる。
2. 統合テスト（Integration Test）
- 対象: コントローラ層＋サービス層（アプリケーション内部の結合）
- 目的: 入力チェック・レスポンス生成・例外ハンドリングが正しく動くか確認
- 特徴: 外部依存はモック化するが、層のつながりは実際に動かす
- 例:
req = null→ 400レスポンスreq.userId = ""→ 400レスポンス- サービス層が
nullを返す → 404レスポンス - サービス層が例外を投げる → 503 or 500レスポンス
👉 早期リターンで「入力チェックの異常系」が明確。
👉 例外処理で「外部要因の異常系」がレスポンスに変換されることを確認。
3. エンドツーエンドテスト（E2E Test）
- 対象: システム全体（UI → コントローラ → サービス → インフラ）
- 目的: 実際のユーザー操作や外部APIとのやり取りを含めて動作確認
- 特徴: モックを使わず、実際の環境でテスト
- 例:
- 正しいユーザーIDを入力 → 実際の外部APIからプロフィール取得 → 200レスポンス
- 存在しないユーザーID → 404レスポンス
- 外部APIがダウン → 503レスポンス
👉 例外処理が「現実の障害」を正しくレスポンスに変換できるかを確認。
まとめ
- ユニットテスト: 業務ロジックをモックで検証（早期リターン・例外発生を確認）。
- 統合テスト: コントローラ＋サービスの結合を確認（レスポンス生成の正しさ）。
- E2Eテスト: 実際の環境で全体の動作を確認（外部要因の例外処理を含む）。
✅ この3層のテスト戦略を組み合わせることで、読みやすく・安全で・テストしやすい設計がさらに強化されます。