モック・スタブ・フェイクのアンチパターン（やってはいけない使い方）
テスト効率化のためにモック・スタブ・フェイクを使うのは有効ですが、誤った使い方（アンチパターン）をすると逆にテストが壊れやすくなり、保守性も落ちます。ここでは代表的なアンチパターンを整理します。
アンチパターン一覧
1. モックの乱用
- 問題: すべての依存をモック化してしまうと「呼び出し確認」ばかりになり、テストが業務ロジックの正しさを保証しなくなる。
- 例: 「DB.save() が呼ばれたか」だけを確認して、保存結果を検証しない。
- 改善: モックは「呼び出し検証」に限定し、結果の検証はスタブやフェイクで行う。
2. スタブの過剰利用
- 問題: 常に固定値を返すスタブを使うと、異常系や例外ケースをテストできない。
- 例: 「APIは必ずユーザーを返す」スタブしか用意せず、エラーケースを再現できない。
- 改善: スタブに「異常系の戻り値」や「例外を投げる」バリエーションを用意する。
3. フェイクを本番に近づけすぎる
- 問題: フェイクを複雑に作り込みすぎると、結局「もう一つの本番システム」を作ってしまう。
- 例: メモリDBフェイクに複雑なクエリ機能を追加して、本物のDBと同じように振る舞わせる。
- 改善: フェイクは「簡易的な代替」に留める。複雑な挙動は統合テストやE2Eで確認する。
4. テストごとに依存の種類がバラバラ
- 問題: ユニットテストでフェイクを使ったり、統合テストでモックを使ったりすると、テストの目的が曖昧になる。
- 改善:
- ユニットテスト → モック／スタブ
- 統合テスト → フェイク
- E2Eテスト → 本物の依存
という役割分担を守る。
5. 例外処理をテストしない
- 問題: モックやスタブを使って「正常系」しかテストせず、例外が発生したときのレスポンスを確認しない。
- 改善: モックに「例外を投げる」設定を入れて、異常系レスポンスを必ずテストする。
まとめ
- モック乱用 → 呼び出し確認ばかりになる
- スタブ過剰利用 → 異常系を再現できない
- フェイク作り込みすぎ → 本番システムの複製になる
- 依存の使い分けが曖昧 → テストの目的がぼやける
- 例外処理未テスト → 本番で落ちるリスク大
✅ 実務では「テストの目的に応じて依存の種類を正しく選ぶ」ことが最も重要です。