ウィキペディアのモック オブジェクトに関する記事を読んだところですが、その目的はまだ完全にはわかりません。これらは、実際のオブジェクトが複雑すぎるか予測できない場合に、テスト フレームワークによって作成されるオブジェクトのようです (モック オブジェクトを完全に制御できるため、モック オブジェクトの値が何であるかは 100% わかります)。
ただし、すべてのテストは既知の値のオブジェクトで行われているという印象を受けていたので、何かが欠けているに違いありません。たとえば、あるコース プロジェクトで、カレンダー アプリケーションを担当しました。テスト スイートは、複数のイベント オブジェクト、さまざまなサブシステム、およびユーザー インターフェイス間の相互作用をテストできるように、それらが何であるかを正確に把握しているイベント オブジェクトで構成されていました。これらはモック オブジェクトだと思いますが、既知の値のオブジェクトがなければシステムをテストできないため、なぜこれを行わないのかわかりません。
モック オブジェクトは、既知の値を持つ単なるオブジェクトではありません。これは、テストで使用できない複雑なオブジェクト (データベース接続や結果セットなど) と同じインターフェイスを持つオブジェクトですが、テストで制御できる実装を備えています。
これらのオブジェクトをオンザフライで作成できるモッキング フレームワークがあり、本質的に次のようなことができます。0 を渡すと、true が返されます。次に、foo() を使用するコードをテストして、適切に反応することを確認します。
Martin Fowler のモッキングに関する素晴らしい記事があります。
クライアント ソフトウェアとサーバー ソフトウェアの典型的なケースを考えてみてください。クライアントをテストするには、サーバーが必要です。サーバーをテストするには、クライアントが必要です。これにより、モックを使用しないと、単体テストがほとんど不可能になります。サーバーをモックすると、クライアントを分離してテストでき、その逆も可能です。
ただし、モックのポイントは、モックするものの動作を複製しないことです。テストフレームワークによって状態の変化を分析できる単純な状態マシンとして機能することはより重要です。したがって、クライアント モックはテスト データを生成し、それをサーバーに送信してから、応答を分析します。特定のリクエストに対して特定のレスポンスが期待されるため、それが得られるかどうかをテストできます。
次に例を示します。データベースにデータを入力するコードを記述している場合、特定のメソッドがデータベースにデータを追加したかどうかを確認する必要があります。
テスト用にデータベースのコピーを設定すると、テストされたメソッドの呼び出しの前にレコードがなく、後に1つのレコードがないと想定した場合、データベースを前の状態にロールバックする必要があり、オーバーヘッドが増えるという問題があります。テストを実行するため。
以前よりもレコードが1つだけ多いと想定すると、同じデータベースに接続している2番目のテスター（または同じコード内の2番目のテスト）と衝突して、依存関係が発生し、テストが脆弱になる可能性があります。
モックを使用すると、テストを互いに独立させ、セットアップを簡単に行うことができます。
これはほんの一例です-他の人がもっと供給できると確信しています。
私は、このトピックに関する他の寄稿者、特にMartinFowlerの記事の推奨事項に100％同意します。
私たちの本に興味があるかもしれません。 http://www.growing-object-directional-software.com/ をご覧ください。これは Java で書かれていますが、アイデアはまだ適用されます。