スタブ vs モック テストで正しい選択をするために抑えておきたい「3つの長所と短所」：過剰使用はテストを硬直化させる可能性も

TechTargetは2024年12月26日、「スタブとモックの違い」に関する記事を公開した。ソフトウェアをテストする際に関数やオブジェクトを置き換える手段としてスタブとモックという2種類の選択肢がある。これらの違いは何か。どう使い分けるべきか。

[Walker Aldridge，TechTarget]

印刷

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

　TechTargetは2024年12月26日（米国時間）、「スタブとモックの違い」に関する記事を公開した。

ソフトウェアのテストにおけるスタブとモックの違い（提供：TechTarget）

　ソフトウェアテストにおいてスタブ（Stub）とモック（Mock）は、関数やオブジェクトの代わりとして機能し、コンポーネントを分離しながら特定の動作を検証するのに役立つ。ファイルが作成されたり、データベースに書き込まれたりといった“テストの副作用”を回避できる。

　単体テストでは、スタブもモックも似たような重要な役割を果たし、開発者はテスト用の環境を制御下に置ける。とはいえ、それぞれの使用方法、適したシナリオ、提供する検証のレベルには違いがある。

　本稿では、スタブとモックの定義、メリット・デメリットを比較し、テストにおいてどちらを選択すべきかを解説する。

ソフトウェアテストにおけるスタブとは

続きを読む

　スタブとは、制御された形で依存関係の動作をシミュレートするための基本的なプレースホルダー（代替物）だ。特定の関数呼び出しに対して、実際のロジックを実行せずにあらかじめ定義された単純な応答を返すように実装されることが多い。

　テストにおけるスタブ（テストスタブ）の主な目的は、テスト対象のコンポーネントから依存関係にある関数やオブジェクトを切り離し、特定のデータや応答を受け取った際の動作テストに集中できるようにすることだ。

テストスタブの例

　例えば、外部APIからデータを取得（フェッチ）する関数があるとする。この関数をテストする際に、実際にAPI経由でネットワークリクエストを発生させるのではなく、代わりにハードコーディングされた応答を返すスタブを使用する。これによって外部APIの可用性や応答速度を気にせず、テスト対象のコンポーネントがデータを処理する部分のテストができる。APIの実装そのものではなく、アプリケーションのロジックに集中してテストを実施できるということだ。

テストスタブの長所

　テストスタブには、モックとは異なる基本的な長所が3つある。

【1．シンプルさ】

　スタブは簡単に作成できる。あらかじめ決められた値を返すだけなので、設定が最小限で済み、管理も容易だ。

【2．一貫性と制御性】

　スタブは事前に定義された値を返すため、テスト結果は安定し、予測の範囲内で収めることができる（つまり、予測可能性と信頼性を確保できる）。テスト環境を制御しやすくなるため、特に「エッジケース」（極端な入力や状況）のテストに役立つ。

【3．安定性】

　スタブは外部コンポーネントや複雑なロジックに依存しないため、環境や依存関係の変化に影響されにくく、安定した動作を提供できる。

テストスタブの短所

　モックと比較した場合、スタブには幾つかの欠点もある。

【1．機能の制限】

　スタブは本質的にシンプルなため、複雑な動作をシミュレートできない。基本的な単体テストには役立つが、コンポーネント同士のより現実的な相互作用（インタラクション）を必要とするテストには適さない。

【2．メンテナンスの負担】

　コードベースが進化するにつれ、実装とスタブを同期させる必要がある。依存するコンポーネントの動作が変更された場合、関連する全てのスタブを更新しなければならず、保守の手間が増える。

【3．検証の不足】

　スタブはあくまで決められた出力を返すだけであり、それがどのように呼び出されたかを検証する機能は持たない。そのため、関数やコンポーネントが適切にスタブとやりとりしているかどうかを確認できず、インタラクションの検証が必要なテストには不向きだ。

ソフトウェアテストにおけるモックとは

　モックは、スタブよりも高度なテストを想定した代替物だ。モックは依存関係の動作をシミュレートするだけでなく、テスト中にどのように呼び出されたかを記録するという特徴がある。モックは動的に動作し、入力パラメーターに応じて異なる応答を返すように設定できるため、特定のメソッドが正しいパラメーターで呼び出されたかどうか、あるいはテスト中に特定のやりとりが発生したかどうかを検証する場面で特に有用だ。

テストモックの例

　例えば、通知メールを送信する関数があるとする。モックを使用することで、想定した宛先やメッセージ内容でメール送信メソッドが呼び出されたかどうかを検証できる。これによって、関数が単に動作するかどうかだけでなく、他のコンポーネントと正しく連携しているかどうかも確認できるため、より信頼性の高いテストが可能になる。

テストモックの長所

　テストにおけるモック（テストモック）の長所は3つある。

【1．インタラクションの検証】

　モックは、特定のメソッドが指定された回数（または特定の引数で呼び出されたかどうか）を検証できる。そのため、モックは関数の呼び出し回数や引数の正確性が重要なテストに向いている。この点がモックとスタブの主な違いだ。

【2．動的な挙動】

　モックは入力に応じて異なる値を返すように設定できるため、より複雑なシナリオをシミュレートできる。この柔軟性によって、入力ごとに動作が変わるようなテストケースに適している。

【3．統合テストのサポート】

　モックは、コンポーネント同士の連携を検証するのに役立つ。特定のメソッドが正しいパラメーターで呼び出されたかどうかを確認できるため、コンポーネント間のインタラクションが適切であることを保証できる。これによって、開発の早い段階で問題を発見できるようになる。

テストモックの短所

　モックの欠点は以下の3点だ。

【1．複雑さ】

　モックは本質的にスタブよりも複雑だ。モックの設定では、その動作の定義や期待するインタラクションの設定が必要なため、特に依存関係の多い大規模システムでは、準備に時間と労力がかかる。

【2．脆弱（ぜいじゃく）さ】

　モックに大きく依存したテストは、基盤となるコードが頻繁に変更されると壊れやすくなる。モックは特定のインタラクションを検証するように構成するため、メソッドのシグネチャ（引数や戻り値の型）や呼び出しパターンの変更に伴って、モックの設定も更新する必要があり、保守の負担が増える。

【3．乱用のリスク】

　モックは強力な手法だが、過度に使用するとテストがコードの中身や具体的な仕組みに密接に依存するようになる。その結果、コードのリファクタリングが妨げられたり、コードのリファクタリングに時間がかかったりしてテストの柔軟性が損なわれる。また、コードの変更時にモックの設定を大幅に見直さなければならなくなる可能性がある。

結論：単体テストにはスタブ、動作検証にはモック

　ソフトウェアのテストにおいて、スタブとモックのどちらを選ぶかは、テストの具体的な要件と実行するテストの種類によって異なる。

　複雑なやりとりがなく、機能の確認に集中できるシンプルなテストにはスタブが向いている。スタブは一貫性と安定性があり、シナリオを分けた独立したテストに向いている。しかし、動作検証の機能はないため、複雑なテストには不向きだ。

　一方、モックはインタラクションの検証が求められるテストに適している。メソッドが正しく呼ばれたのかどうか、期待した動作が発生したかどうかを確認できるため、テストの複雑さが増すほど効果が高くなる。ただし、モックは設定が複雑で壊れやすく、コードの変更によって頻繁に更新が必要になる可能性があるため、使い過ぎには注意が必要だ。

　スタブとモックは、どちら一方が優れているわけではなく、果たす目的がそれぞれ異なっている。包括的なテストを実現するには、スタブの「シンプルさと制御のしやすさ」と、モックの「動的な挙動やインタラクションの検証機能」を組み合わせるのが最も効果的な戦略と言える。