多くの人は、単体テストを作成するときにモック オブジェクトを使用します。モックオブジェクトとは?なぜ私はそれが必要なのですか?モック オブジェクト フレームワークは必要ですか?
9 に答える
オブジェクト モッキングは、依存関係を単体テストから除外するために使用されます。データベースから人を選択して Person オブジェクトを返す "SelectPerson" のようなテストがある場合があります。
これを行うには、通常、データベースへの依存関係が必要になりますが、オブジェクトのモックを使用すると、モック フレームワークを使用してデータベースとのやり取りをシミュレートできるため、データベースから返されたデータセットのように見えるデータセットが返され、テストすることができます。コードを使用して、データベースへの接続が存在することをテストするのではなく、データセットから人物オブジェクトへの変換を確実に処理するようにします。
何人かがすでに「何」に答えていますが、私が思いつく簡単な「理由」は次のとおりです。
パフォーマンス
単体テストは高速である必要があるため、ネットワーク、データベース、またはその他の時間のかかるリソースと対話するコンポーネントのテストは、モック オブジェクトを使用して行われた場合、ペナルティを支払う必要はありません。節約はすぐに加算されます。
コラボレーション
他の誰かのコード (まだ作成されていないか、並行して開発されている - 一般的なシナリオ) と対話する必要がある、適切にカプセル化されたコードを作成している場合は、一度モック オブジェクトを使用してコードを実行できます。インターフェイスは合意済みです。そうしないと、他のコンポーネントが完了するまでコードのテストが開始されない可能性があります。
モック オブジェクトを使用すると、書いている内容だけでなく、リソース (ディスク、ネットワーク サービスなど) へのアクセスなどの抽象的な詳細に対してもテストできます。モックを使用すると、その外部リソースやクラスなどのふりをすることができます。
モック オブジェクト フレームワークは本当に必要ありません。テストで気にしたくない機能のクラスを拡張し、テストしているクラスが本物の代わりにモックを使用できることを確認してください (コンストラクターまたはセッターなどを介して。
練習すれば、モックが役立つときとそうでないときがわかります。
編集:リソースをモックすることは特に重要であるため、テスト中にそれらが存在することに依存する必要はありません。また、それらがどのように存在し、何に応答するかの詳細をモックすることができます (FileNotFoundException のシミュレート、または欠落している Web サービスなど)。 、またはWebサービスのさまざまな可能な戻り値)...すべてに関連する遅いアクセス時間はありません(モックは、テストでそのようなリソースにアクセスするよりもはるかに高速であることが証明されます)。
モックオブジェクトフレームワークが必要ですか?
確かに違います。時々、手でモックを書くことはかなり退屈かもしれません。しかし、単純なことについては、それはまったく悪いことではありません。Last Responsible Momentの原則をモックフレームワークに適用すると、手書きのモックが価値よりも厄介であることが自分自身に証明された場合にのみ、手書きのモックからフレームワークに切り替える必要があります。
モックを始めたばかりの場合、フレームワークに直接ジャンプすると、少なくとも学習曲線が2倍になります(曲線を2倍にすることはできますか?)。いくつかのプロジェクトを手作業でモックを作成するのに費やした場合、フレームワークのモックははるかに理にかなっています。
オブジェクトのモッキングは、インターフェイス、抽象クラス、または仮想メソッドを持つクラスから「仮想」またはモック オブジェクトを作成する方法です。テスト目的で、これらのいずれかを独自の定義にラップすることができます。テストしている特定のコード ブロックに依存するオブジェクトを作成するのに役立ちます。
私がよく使うのはMoqと呼ばれるものですが、RhinoMock のようなものは他にもたくさんあり、私が知らないものもたくさんあります。
これにより、プロジェクトの一部が残りの部分とどのように相互作用するかをテストできます。全体を構築したり、重要な部分を見逃す可能性はありません。
編集: ウィキペディアの素晴らしい例: 車の設計者がクラッシュ テスト ダミーを使用して事故時の車の挙動をテストするように、事前にコードをテストできます。
もう 1 つの用途は、まだ構築されていないシステムの他の部分に対してテストできるようにすることです。たとえば、あなたのクラスが、他の誰かが取り組んでいる機能の一部である他のクラスに依存している場合、ほぼ完全なインターフェースを要求し、そのインターフェースに対してプログラムを作成し、期待どおりに動作するように詳細をモックすることができます。次に、インターフェイスに関する想定が正しいことを確認します (開発中、または機能が完成した後)。
モックフレームワークが役立つかどうかは、作成しているコードの言語に一部依存します。静的言語では、コンパイラーをだましてモックオブジェクトを本物の代わりとして受け入れるようにするために、余分な労力を費やす必要があります。Python、Ruby、Javascriptなどの動的型付け言語では、通常、メソッドを任意のオブジェクトまたはクラスにアタッチし、それをパラメーターとして渡すことができます。そのため、フレームワークははるかに少ない値を追加します。
.net ユニット テストに推奨される 2 つのモック フレームワークは、Typemock Isolator と Rhino Mock です。
次のリンクでは、ユニット テストにモッキング フレームワークが必要な理由に関する Typemock の説明を参照できます。