質問

モックの目的は何ですか？

私は、テストにNUnitを使用し、モックにMoqを使用するASP.NET MVCチュートリアルに従っています。ただし、そのモック部分については少しわかりません。

役に立ちましたか？

解決

モックの目的は、テスト対象のクラスを他のクラスから分離することです。

これは、クラスが次の場合に役立ちます：

  • 外部リソース（FileSystem、DB、ネットワークなど）に接続します
  • セットアップに費用がかかる、またはまだ利用できない（ハードウェアが開発中）
  • 単体テストの実行を遅くします
  • 非決定論的な動作があります
  • ユーザーインターフェイスを持っている（または持っている）

また、エラー状態をテストすることも簡単になります。モックオブジェクトをビルドして、エラーを返し、例外をスローするようにします...

モックは、どのように呼び出されたか（関数呼び出しの順序、パラメーター）を記録でき、これはテストによって検証できます。編集：例えば： テストしているメソッドは、IPCなどのメッセージを送信します。モックオブジェクトのメソッドは、呼び出された回数を記録できます。 彼が受信したパラメーター（つまり、送信されるメッセージ）。次に、テストはモックオブジェクトに問い合わせて、送信されたメッセージの数、メッセージの内容をアサートできます... 同様に、モックオブジェクトは、ログ文字列で呼び出されるメソッドを記録でき、テストはその文字列を取得してアサートできます。

モックオブジェクトを悪用しないでください：実装ではなく動作をテストします。そうしないと、ユニットテストがコードと密結合し、脆弱になります（リファクタリングで中断します）。

モックは手動でコーディングするか、モックフレームワークによって生成できます。

他のヒント

モッキングにより、テスト中のクラスをその依存関係から分離できます。通常、テスト対象のクラスの依存関係ごとにモックを作成し、モックを設定して期待される値を返します。次に、テスト対象のクラスが依存しているクラスの実際のコピーの代わりに、テスト対象のクラスにモックを提供します。その後、モックフレームワークを使用して、モックオブジェクトに対して予期される呼び出しが行われたことを確認し、テスト対象のクラスが正しく動作していることを確認できます。

これは、グループコレクションの個々のインスタンスを面白がるように設計されています。不規則なオブジェクトの集まりで多く使用しました。

通常、モックはテスト対象のクラスの分離を可能にするものとして理解されていますが、これはモックの主要なポイントではありません（スタブの方が適しています）。代わりに、オブジェクトが3つのことの1つである何かを行うように指示されたときに何が起こるかを調べる必要があります。

  1. 直接出力-メソッド呼び出しの結果
  2. 内部の変更-メソッド呼び出し中のクラスの変更
  3. 間接出力-テスト中のコードは別のクラスを呼び出します

状態ベースのテストは、すべて＃1と＃2についてです。 ＃1メソッドが提供する結果を見ること。 ＃2オブジェクトの内部状態にアクセスする。

これにより、私たちが取ることができる2つの道がある＃3が残ります。 1つ目はモックを使用する方法で、2つ目はテストスパイを使用する方法です。主な違いは、モックではテスト対象のコードを実行する前に期待値を作成してからモックで検証するのに対し、テストスパイではテスト対象のコードを実行してから特定のアクションが発生したかどうかをテストスパイに尋ねることです。

つまり、すべてをまとめると、モックの出番である間接出力（別名別のクラスの呼び出し）をテストする必要がある場合に、クラスの動作をテストすることを考えるときです。

私もモックをするのは初めてですが、これを突き刺します。私の経験では、モックには2つの主な利点があります：

  • 実際に実装を記述する前に、オブジェクトの操作を開始できます。インターフェイスを定義し、モックを使用して、単体テストまたはコードでインターフェイスを操作できます。
  • モックを使用すると、単体テストでテスト対象のオブジェクトを分離できます。モックオブジェクトを使用すると、テスト対象のオブジェクトがやり取りするオブジェクトを完全に制御できるため、テストから外部依存関係を削除できます。

＆quot;モック＆quot; ＆amp;のテストで非常に過負荷な用語です。 TDDサークル。 Martin Fowlerの記事 Mocks Aren's Stubs を参照してください。 「適切な」モックは、受け取るべき値を知っており、意図したものが得られない場合に通知します。これにより、状態テストの代わりに相互作用テストを実行できます。テスト中のクラスが正しいメッセージを正しい順序で協力者に渡していることを確認します。相互作用テストは、従来の状態テストとはまったく異なり、頭を悩ますことは困難です。相互作用テストはモックのポイントであり、モックを理解しやすくする可能性があることに留意してください。

バートF

によるモックの優れたリアルタイムの例

単体テスト

このシステムの単体テストを想像してください：

cook <- waiter <- customer

一般に、 cook のような低レベルコンポーネントのテストは容易に想像できます。

cook <- test driver

テストドライバーは、単に異なる料理を注文し、料理人が注文ごとに正しい料理を返すことを確認します。

他のコンポーネントの動作を利用するウェイターなどの中間コンポーネントをテストするのは困難です。素朴なテスターは、クックコンポーネントをテストしたのと同じ方法で、ウェイターコンポーネントをテストできます。

cook <- waiter <- test driver

テストドライバーは異なる料理を注文し、ウェイターが正しい料理を返すようにします。残念ながら、これは、ウェイターコンポーネントのこのテストがクックコンポーネントの正しい動作に依存する可能性があることを意味します。この依存関係は、非決定的な動作（メニューには料理としてのシェフの驚きが含まれています）、多くの依存関係（料理人はスタッフ全員がいないと調理しません）、またはリソース（一部の料理は高価な材料を必要とするか、調理に1時間かかります）。

これはウェイターテストなので、理想的には、料理人ではなくウェイターのみをテストする必要があります。具体的には、ウェイターがお客様の注文を料理人に正しく伝え、料理人の食べ物をお客様に正しく配達するようにします。

ユニットテストはユニットを個別にテストすることを意味するため、ファウラーは、テストダブル（ダミー、スタブ、偽物、モック）を呼び出します。 

    -----------------------
   |                       |
   v                       |
test cook <- waiter <- test driver

ここでは、テストクックは「in cahoots」です。テストドライバーで。理想的には、テスト対象のシステムは、テストクックを簡単に置き換えることができるように設計されています（注入）生産コードを変更せずにウェイターを操作するには（たとえば、ウェイターコードを変更せずに）。

モックオブジェクト

今、テストクック（テストダブル）はさまざまな方法で実装できます：

  • 偽の料理人-冷凍ディナーと電子レンジを使用して料理人のふりをする人、
  • スタブクック-何を注文しても常にホットドッグを提供するホットドッグベンダー、または
  • モッククック-刺すような操作で料理をするふりをするスクリプトに従った覆面警官。

偽物、スタブ、モック、ダミーの詳細については、ファウラーの記事をご覧ください 、しかし今のところ、模擬料理に焦点を当てましょう。

    -----------------------
   |                       |
   v                       |
mock cook <- waiter <- test driver

ウェイターコンポーネントをテストするユニットの大部分は、ウェイターがクックコンポーネントと対話する方法に焦点を当てています。モックベースのアプローチは、正しい相互作用が何であるかを完全に指定し、それがいつうまくいかないかを検出することに焦点を当てています。

モックオブジェクトは、テスト中に何が起きるか（たとえば、どのメソッド呼び出しが呼び出されるかなど）を事前に知っており、モックオブジェクトはどのように反応するか（たとえば、どの戻り値を提供するか）を知っています。モックは、実際に起こることと起こるはずのこととが異なるかどうかを示します。カスタムモックオブジェクトは、各テストケースの予想される動作に合わせてコーディングできますが、モックフレームワークは、そのような動作仕様をテストケースで明確かつ簡単に直接示すことができるように努めています。

模擬ベースのテストに関する会話は次のようになります。

  

テストドライバーから模擬料理：ホットドッグの注文を期待し、それに応答してこのダミーのホットドッグを彼に渡します

     

テストドライバー（顧客としてポーズ）からウェイター

もう1つの答え：

  • スタブ=実際のコンテキスト全体なしでテストを実行できるようにする偽のオブジェクト

  • モック=コンポーネントの相互作用を記録し、これらの相互作用を検証するための偽のオブジェクト

1つのテストで複数のスタブを使用できますが、モックが1つしかない場合は、1つ以上の機能をテストする必要があります。

基本を超えて、モックはコンポーネントの動作を確認するテストの従来の状態検証よりも動作検証です（Arrange、Act、Assert with Mocks it is more Arrange、Act、Verify ）：

状態検証Assert.AreEqual（valueExpected、mycomponent.Property）; 動作検証：myMock.WasCalled（MyMethod）;

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top