レストランで料理を注文する時、まだ作れないメニューの代わりに写真を見せてもらうのがモック。一方、料理人が他の仕事で忙しい時、見習いシェフが簡単なサラダを作るのがスタブです。テストの世界では、これらを使ってシステム全体を動かさなくても、一部分だけを安全に確認できるんです。
面接官：モック / スタブについて説明してください。
私：モックとスタブは、ソフトウェアテストにおいて、依存するコンポーネントやサービスを代替する役割を果たします。モックは、テスト対象のコンポーネントに対する *入力* に基づいて、期待される *出力* を検証するために使用されます。一方、スタブは、テスト対象のコンポーネントから *呼び出される* 依存コンポーネントの単純な代替として機能し、あらかじめ定義された固定の値を返します。
以前のプロジェクトで、外部APIに依存する会員登録機能をテストする際に、モックとスタブを導入しました。APIが不安定でテストが頻繁に失敗していたため、モックを使ってAPIのレスポンスを固定化し、会員登録機能自体のロジックに集中してテストできるようになりました。さらに、API側の開発が遅れていた部分については、スタブを用いて代替のレスポンスを返すようにしました。これにより、APIが未完成の状態でも会員登録機能の開発を進めることができ、結果として納期遅延を防ぐことができました。
現役エンジニアによる深掘り解説
メリット
テストの独立性: 依存するコンポーネントの状態に左右されずに、テスト対象のコンポーネントに焦点を当てたテストができます。
テストの再現性: モックやスタブの動作を固定することで、常に同じ結果が得られる再現性の高いテストができます。
開発の加速: 依存コンポーネントの開発が遅れている場合でも、モックやスタブを使ってテスト駆動開発（TDD）を進めることができます。
コスト削減: 外部APIの呼び出しなど、コストのかかる処理をモックで代替することで、テストコストを削減できます。
デメリット
実装と乖離するリスク: モックやスタブの実装が、実際のコンポーネントの動作と異なると、誤ったテスト結果になる可能性があります。
保守コストの増加: モックやスタブは、テスト対象のコンポーネントだけでなく、依存コンポーネントの変更にも追従して修正する必要があります。
過度な依存: モックやスタブに頼りすぎると、結合テストや統合テストが疎かになり、システム全体の品質が低下する可能性があります。
⚠️ 面接突破のワンポイント
- モックとスタブの違いを明確に説明できるように準備しましょう。具体的なシナリオ（例：会員登録、ログイン）を想定して、どちらをどのように使用するかを説明できるようにしておくと効果的です。
- モックやスタブを導入したことで、テストの効率や品質がどのように向上したかを定量的に説明できるようにしておくと、より説得力が増します。（例：テスト実行時間が〇〇%短縮、バグの検出数が〇〇%増加）
