モックとは何か——スタブ・スパイとの違いをテスト実務の視点で整理する

開発品質の議論に「モック」が登場する理由——テスト工程の全体像から読み解く

システム開発の進捗報告や品質レビューの場で、「モックを使ってテストしました」「スタブで代替しています」といった言葉が登場することがあります。開発を委託している立場からすると、何となく聞き流してしまいがちな表現ですが、これらはテスト工程の設計思想に直結する重要な概念です。

単体テスト・結合テスト・システムテストの立ち位置を整理する

ソフトウェア開発のテストには、大きく三つの段階があります。

• 単体テスト：個々の部品（関数やクラスなど）が、単独で正しく動くかを確認する工程
• 結合テスト：複数の部品を組み合わせたとき、それぞれが連携して正しく機能するかを確認する工程
• システムテスト：システム全体を通じて、要件どおりに動作するかを確認する工程

発注側が目にしやすいのはシステムテストの結果ですが、その手前にある単体テストと結合テストの品質が、最終的な完成度を大きく左右します。特に単体テストの段階で欠陥を早期に発見できるかどうかが、後工程の手戻りを減らす鍵になります。

テスト時に「本物の部品」をそのまま使えないケースとは

単体テストでは、ある部品だけを取り出して動作を確認します。しかし実際のシステムでは、一つの部品が別の部品や外部サービスと連携していることがほとんどです。たとえば、注文処理のモジュールをテストしようとすると、在庫管理システムや決済サービスとの接続が必要になります。

このとき、本物の外部システムをそのままテストに使うことが難しいケースが少なくありません。具体的には、次のような状況が挙げられます。

• 外部の決済サービスに実際の通信を行うと、課金が発生してしまう
• 連携先のシステムがまだ開発中で、利用できる状態にない
• 本番環境の外部APIへの接続が、セキュリティポリシー上、テスト環境から許可されていない
• エラー発生など、再現が難しい特定の状況を意図的に作り出す必要がある

このような制約があると、部品単体の品質を独立して確認することが困難になります。

テストダブルという考え方が生まれた背景

こうした問題を解決するために生まれたのが、テストダブルという考え方です。「ダブル」とは映画の代役（スタントダブル）から来た言葉で、本物の代わりに使う「代替部品」を総称する概念です。

テストダブルを使うことで、本物の外部システムや未完成のモジュールがなくても、テスト対象の部品だけを切り出して検証できるようになります。モックはこのテストダブルの一種であり、スタブやスパイなども同じカテゴリに属します。

発注側の立場でモックという言葉が出てきたとき、それは「テスト工程を適切に設計し、部品単位での品質検証を行っている」という文脈で理解するのが適切です。次のセクションでは、テストダブルの種類と、それぞれの役割の違いを整理します。

テストダブルとは何か——5種類の代替部品を一覧で理解する

テストダブルの定義——本物の部品の代わりを務める「影武者」

テストダブル（Test Double）とは、ソフトウェアのテスト時に、本物のコンポーネント（外部システム・データベース・APIなど）の代わりとして使う「代替部品」の総称です。

映画撮影における「スタント俳優」を想像すると理解しやすいです。本物の俳優がすべてのシーンに出演できないように、テスト環境でも本物のシステムをそのまま使えないケースが多くあります。テストダブルはその代役を務め、テストが成立するための条件を整える役割を担います。

なぜ5種類もあるのかというと、「代役に何をさせたいか」によって適切な道具が変わるからです。状況を確認するだけでいい場面もあれば、特定の返答を返させたい場面、呼び出しの記録を残させたい場面もあります。目的ごとに最適な代役の形が異なるため、テストダブルは自然と5種類に分類されるようになりました。

5種類のテストダブルを一覧で比較する【表】

それぞれが「何を解決するために存在するか」を押さえる

5種類の違いを整理する上で重要なのは、「何の不便を解消するために作られたか」という視点です。

• Dummy：テストの記述形式を満たすための最小限の穴埋め役。動作には関与しません。
• Stub：外部依存（APIや決済システムなど）を切り離すための代役。決まった値を返すことでテストを安定させます。
• Spy：処理の呼び出し事実を記録・確認したい場面で使います。本物に近い動きを保ちつつ、履歴を取得できます。
• Mock：「呼ばれ方そのもの」を検証したい場合に使います。スパイより厳格で、期待と異なる呼び出しがあればテストを失敗させます。
• Fake：テスト環境で本物に近い挙動が必要な場面で使います。本番システムの代わりとして動く、軽量な実装を持ちます。

発注側の立場で覚えておきたいのは、「モック」はテストダブル全体の総称として使われることも多い一方、厳密には5種類のうちの1つに過ぎないという点です。委託先との会話でこの区別を意識しておくと、テスト設計の議論を正確に把握しやすくなります。

モックとは何か——スタブ・スパイとの本質的な違い

モックの定義——「期待した呼び出しがされたか」を検証する部品

モック（Mock）とは、テスト対象のコードが「正しい相手を、正しいタイミングで、正しい方法で呼び出したか」を検証するための代替部品です。

たとえば、受発注システムが注文確定時に「メール送信機能を呼び出す」という仕様があるとします。このとき、実際のメールサーバーを使わずにテストするために、メール送信機能をモックに置き換えます。テスト実行後、モックは「呼び出しが1回あったか」「宛先アドレスは正しかったか」という事実を検証します。

ここで重要なのは、モックが検証するのは「振る舞い」だという点です。処理の結果として何が返ってきたかではなく、処理の過程で何がどのように実行されたかを確認します。

スタブとの違い——戻り値を返すだけか、呼び出しまで検証するか

スタブ（Stub）は、テスト対象のコードに「あらかじめ決めた戻り値」を返すことだけを目的とした代替部品です。モックとよく混同されますが、役割が異なります。

先ほどの例で言えば、スタブは「在庫確認APIを呼び出したときに、常に『在庫あり』と返す」といった使い方をします。テスト対象が正しく動作するための入力条件を整えるのがスタブの役割であり、その後「何回呼ばれたか」「どんな引数だったか」は関知しません。

整理すると、スタブは「状態の検証」を支援する部品です。処理結果が正しいかどうかを確認するために、前提となるデータを供給します。モックはそれに加えて、呼び出し自体が正しく行われたかという「振る舞いの検証」まで担います。

スパイとの違い——事後に記録を確認するか、事前に期待値を設定するか

スパイ（Spy）は、実際の処理を実行しながら呼び出しの記録だけを残す部品です。モックと似て「振る舞い」を対象にしますが、検証のタイミングと設計の方向性が逆になります。

モックはテスト実行前に「こう呼ばれるはずだ」という期待値を設定しておき、実行後に期待通りだったかを自動で判定します。一方スパイは、実行後に記録されたログをテストコード側で確認する形をとります。スパイは「事後確認型」、モックは「事前期待型」と言い換えることができます。

スパイは既存の実処理を残しつつ監視したい場合に向いており、モックは呼び出しの正しさそのものをテストの主目的にしたい場合に適しています。

モック・スタブ・スパイの使い分けを判断する3つの問い

発注側がベンダーとの会話でこれらの用語が出てきたとき、以下の問いを頭に置いておくと理解が整理されます。

テスト設計の議論でモックという言葉が出てきたときは、「戻り値を用意しているのか、呼び出しの正しさを検証しているのか」を確認するだけで、会話の精度が大きく変わります。

実務での使い方——モックが活きる3つの典型シナリオ

モックの概念を理解したうえで、次に押さえておきたいのが「実際にどのような場面で使われているか」という実務上の文脈です。ここでは、開発現場でモックが特に効果を発揮する3つのシナリオを取り上げます。それぞれ「何の代わりにモックを置いているのか」「何を検証したいのか」をセットで整理します。

シナリオ1：外部API（決済・地図・認証など）が絡む機能のテスト

決済サービスや地図情報、外部認証基盤など、サードパーティのAPIと連携する機能は多くのシステムに存在します。こうした外部APIを実際に呼び出しながらテストを行うと、通信費が発生したり、テスト用の本番環境を用意する手間がかかったりします。また、相手側のサービスが一時停止しているだけでテスト全体が止まってしまうリスクもあります。

このシナリオでは、外部APIの代わりにモックを置き、「APIからこういうレスポンスが返ってきたとき、自分たちのシステムが正しく動くか」を検証します。正常系だけでなく、エラーレスポンスやタイムアウトなど、実際の外部APIでは再現しにくい異常系のテストも、モックであれば自在に設定できます。

シナリオ2：データベースへの書き込み・読み込みを含む機能のテスト

会員情報の登録や注文データの保存など、データベースへの読み書きを伴う処理のテストでは、毎回テスト用のデータを準備・削除する手間がかかります。テスト件数が増えるほど処理時間も長くなり、開発のスピードを落とす原因になりがちです。

ここではデータベースの代わりにモックを置き、「データが正しく渡されているか」「保存後に想定どおりの処理が呼ばれているか」を検証します。実際のデータベースを使わないため、テスト環境のデータが汚染されるリスクも避けられます。処理ロジック自体の品質を素早く確認したい場面で、特に効果を発揮するシナリオです。

シナリオ3：メール送信・Slack通知など副作用を伴う機能のテスト

ユーザー登録時の確認メール、注文完了通知、Slackへのアラート送信など、外部への出力を伴う処理はテストに注意が必要です。テストのたびに実際にメールが送信されたり、Slackチャンネルに通知が届いたりすると、現場が混乱するうえ、テストの再現性も担保しにくくなります。

このシナリオではメール送信機能や通知機能の代わりにモックを置き、「送信処理が正しいタイミングで呼ばれたか」「宛先や本文のパラメータが正しく渡されているか」を検証します。実際には何も送信せずに、送信処理への指示が正しく届いているかどうかを確認できる点が、モックならではの強みです。

モックの使いすぎが招くリスク——発注側が知っておきたい品質上の注意点

モックはテストを効率化する便利な道具ですが、使いすぎると逆に品質リスクを高めます。CLANEが開発支援の現場で繰り返し目にしてきた実態として、モックに過度に依存したテスト設計は、単体テスト段階では問題が見えにくく、結合後に初めて不具合が露見するケースが少なくありません。発注側がこのリスクを知っておくことは、納品物の品質を正しく評価するうえで重要です。

モックはあくまで「隔離」のための道具——本番と同じ環境での検証は別途必要

モックの本質的な役割は、テスト対象を外部の依存関係から切り離して検証することです。たとえば外部APIや決済サービスをモックに置き換えれば、開発初期から単体テストを進められます。しかしこの「隔離」が目的である以上、モックはあくまで本番連携の代替にはなりません。

実際の外部サービスとの通信仕様、レスポンスの遅延、エラー時の挙動——こうした要素はモックでは再現できないことがほとんどです。単体テストでモックを使うこと自体は正しい判断ですが、それとは別に、本番に近い環境での結合テストや受入テストを計画に組み込む必要があります。

モック依存のテスト設計が引き起こしがちな3つの落とし穴

• 仕様のズレが検出されない：モックは開発者自身が「こういう動作をするはず」という前提で作成します。その前提が誤っていれば、テストは通っても実際の連携では失敗します。
• 結合後に不具合が集中する：モックで隔離したまま単体テストを積み重ねると、複数モジュールをつなげた段階で初めてインターフェースの不一致や依存関係の問題が表面化します。
• テストカバレッジが過大評価される：テスト件数が多くても、その多くがモックを前提とした検証であれば、本番環境での品質保証にはなりません。

発注側が確認すべき「テスト計画書」の読み方

ベンダーからテスト計画書を受け取った際は、単体テストの件数だけでなく、結合テストと受入テストが独立して計画されているかを確認することが重要です。具体的には次の点を確認してください。

• モックや스タブを使用する範囲と、本番環境に近い条件で実施するテストの範囲が明示されているか
• 外部サービスとの実接続テストがいつ、どの環境で実施されるか
• 結合テストの合否基準と、不具合発生時の対応フローが記載されているか

「テストを十分に行っています」という説明を受けた場合でも、その内容がモック中心の単体テストに偏っている可能性があります。モックで代替できるのは依存部品の隔離による動作確認までであり、実際の連携品質の保証は結合テスト以降の工程が担うものです。この区別を理解しておくだけで、ベンダーとの品質に関する議論の精度が大きく変わります。

よくある混乱を整理する——「フェイク」「ダミー」はモックと何が違うか

モック・スタブ・スパイの違いを整理した後で、もう一点補足しておきたい概念があります。ベンダーとの会話に「フェイク」「ダミー」という言葉が登場したとき、それらをモックと混同してしまうケースが少なくありません。5種類のテストダブルを正確に区別するために、それぞれの位置づけを確認しておきましょう。

Fake（フェイク）——動くが本物より簡略化された代替実装

フェイクは、実際に動作するコードを持ちながら、本番環境とは異なる簡略化された実装を指します。代表的な例がインメモリデータベースです。本番では大規模なRDBMS（リレーショナルデータベース管理システム）を使うところを、テスト時はメモリ上に擬似的なデータストアを構築して代替します。

モックやスタブが「応答を返すだけの代替部品」であるのに対し、フェイクは「動くが軽量な代替システム」という点で異なります。テスト速度の向上や外部依存の排除を目的として使われることが多く、単体テストよりも結合テストに近い場面で登場します。

Dummy（ダミー）——引数を埋めるためだけに存在するオブジェクト

ダミーは、メソッドの引数として渡す必要があるが、テスト中には実際には使われないオブジェクトです。たとえば「利用者オブジェクトを引数に受け取る関数」をテストする場合に、その利用者オブジェクトの中身がテストの本質と無関係であれば、ダミーとして空のオブジェクトを渡すだけで済みます。

ダミーには挙動の検証も値の返却も期待されていません。あくまでコードを動かすための「形式的な穴埋め」であり、この点でモック・スタブ・スパイとは目的が根本的に異なります。

5種類の使い分けを一枚で判断するフローチャート【図解】

テストダブルの5種類を選ぶ際は、次の問いを順に確認すると整理しやすくなります。

1. 引数を埋めるだけで、実際には使わないか？——「はい」なら Dummy（ダミー）
2. 本番に近い動作をする軽量な代替実装が必要か？——「はい」なら Fake（フェイク）
3. 固定の戻り値を返すだけでよいか？——「はい」なら Stub（スタブ）
4. 呼び出し履歴を後から確認したいか？——「はい」なら Spy（スパイ）
5. 呼び出し内容の検証まで事前に定義したいか？——「はい」なら Mock（モック）

「テストダブルとは」という問いに対して単に「モック」と答えるだけでは、実態の一部しか説明できていません。5種類それぞれに役割があり、適切に使い分けることがテスト設計の精度を高める前提になります。発注側の担当者としては、ベンダーがどの種類をどの目的で使っているかを問いかけられる状態を目指すことが、品質管理の実効性につながります。

まとめ——「モックとは何か」を発注側の言葉で整理する

この記事で解説してきた内容を、発注側の視点から改めて整理します。開発委託先との会話でこれらの用語が登場したとき、それぞれ次のように読み解いてください。

• テストダブルとは、本物の部品の代わりにテスト用として使う「代替部品」の総称です。モック・スタブ・スパイ・フェイク・ダミーはすべてこの一種にあたります。
• スタブとは、外部システムや未完成の機能から「決まった返答を返すだけ」の代替部品です。テスト対象に都合のよいデータを渡すために使います。
• モックとは（テストの文脈では）、「正しい呼び出しが行われたかどうか」を検証する代替部品です。スタブが入力を制御するのに対し、モックは出力側の振る舞いを確認します。
• スパイとは、本物の部品として動作しつつ、呼び出しの記録だけを残す代替部品です。モックほど厳格ではなく、後から確認できる点が特徴です。

テスト設計の妥当性を発注側が確認する際は、以下のポイントを委託先に確認する手がかりとして活用してください。

• モックが多用されていないか。モックの数が増えるほど、実際の動作環境と乖離したテストになりやすい傾向があります。
• スタブで代替している外部連携に、後から本番相当のテストが計画されているか。スタブはあくまで暫定手段です。
• テストダブルの種類と使用箇所が設計書やテスト仕様書に明記されているか。記録がない場合、品質状況の把握が困難になります。
• 結合テスト・システムテストの段階でテストダブルを外す計画があるか。単体テスト以降もモックのまま進んでいるケースには注意が必要です。

モックとスタブの違いは一見細かい技術的な話に見えますが、どの部分をどのような前提でテストしているかを把握することは、発注側が品質リスクを正しく評価するために欠かせない視点です。委託先の説明に対して、これらの用語を手がかりに「何を確認し、何を確認していないか」を問いかけることが、テスト工程への実質的な関与につながります。