7

私は現在、モック オブジェクト (この特定のケースでは nSubsitute) を利用して、単体テストを拡張しています。しかし、モックオブジェクトを作成するときの現在の知恵は何だろうと思っています。たとえば、データを取得して処理するためのさまざまなルーチンを含むオブジェクトを使用しています。ここでは大したことではありませんが、かなりの数のテストで使用されます。

ほとんどのテスト プロジェクトでモック化された適切なメソッドと動作をすべて備えたモック オブジェクトを返す共有関数を作成し、そのオブジェクトを単体テストに呼び出す必要がありますか? または、オブジェクトをすべての単体テストにモックし、そのテストに必要な動作のみをモックします (ただし、同じ動作を複数回モックする場合もあります)。

感想やアドバイスはありがたく頂戴いたします。...

4

3 に答える 3

10

これについて合意された「現在の知恵」があるかどうかはわかりませんが、ここに私の2セントがあります.

まず、@codebox が指摘したように、単体テストを互いに独立して実行する必要があるため、単体テストごとにモックを再作成することをお勧めします。そうしないと、一緒に実行するとテストに合格しても、単独で実行すると失敗する (またはその逆) 可能性があります。テストに必要なモックの作成は、通常、テスト セットアップ ( [SetUp]NUnit では、XUnit ではコンストラクター) で行われるため、各テストは新しく作成されたモックを取得します。

これらのモックの構成に関しては、状況とテスト方法によって異なります。私の好みは、必要最小限の構成で各テストでそれらを構成することです。これは、テストがその依存関係に何を必要としているかを正確に伝える良い方法です。これらの場合、いくつかの重複があっても問題はありません。

多数のテストで同じ構成が必要な場合は、シナリオ ベースのテスト フィクスチャ (リンクの免責事項: 恥知らずな自己宣伝)の使用を検討します。シナリオは のようなものである可能性がWhen_the_service_is_unavailableあり、そのシナリオのセットアップでは、モックされたサービスが例外をスローするか、エラー コードを返すように構成できます。次に、各テストは、その共通の構成/シナリオに基づいてアサーションを作成します (たとえば、エラー メッセージを表示する必要がある、管理者に電子メールを送信する必要があるなど)。

構成の重複ビットが多数ある場合の別のオプションは、Test Data Builderを使用することです。これにより、モックやその他のテストデータのさまざまな側面を構成する再利用可能な方法が提供されます。

最後に、大量の構成が必要な場合は、テスト依存関係のインターフェースを変更して「おしゃべり」を少なくすることを検討する価値があるかもしれません。テスト対象のクラスに必要な呼び出しの数を減らす有効な抽象化を探すことで、テストで構成する必要が少なくなり、そのクラスが依存する責任を適切にカプセル化できます。

いくつかの異なるアプローチを試して、何が効果的かを確認する価値があります。重複の除去は、各テスト ケースの独立性、シンプルさ、保守性、信頼性を維持することとバランスを取る必要があります。小さな変更で多数のテストが失敗する場合、または個々のテストに必要な構成を理解できない場合、またはテストが実行される順序によって失敗する場合は、次のことを行う必要があります。アプローチを改善します。

于 2012-08-15T23:30:51.183 に答える
2

テストごとに新しいモックを作成します。それらを再利用すると、以前のテストのモックの状態が後のテストの結果に影響を与えるという予期しない動作が発生する可能性があります。

于 2012-08-15T10:20:01.943 に答える
1

特定のケースを見ずに一般的な答えを提供することは困難です。

私は他のどこでも行っているのと同じアプローチに固執します。まずテストを独立した存在として見てから、類似点を探して共通部分を抽出します。

ここでの目標は、要件が変更された場合にテストを維持できるように、DRYに従うことです。

そう...

  1. グループ内のすべてのテストが同じ模擬動作を使用することが明らかな場合は、共通の設定でそれを提供します

  2. モックのコンテンツがテスト対象の重要な部分を構成し、テストとモックの関係が 1:1 のように見える場合、それらのそれぞれが大幅に異なる場合は、それらをテストの近くに保つことが合理的です。

  3. それらの間でモックが異なるが、ある程度だけ異なる場合でも、冗長性は避けたいと考えています。一般的なセットアップは役に立ちませんが、PrepareMock(args...)さまざまなケースをカバーするようなユーティリティを導入することをお勧めします。これにより、実際のテスト方法を繰り返し設定する必要がなくなりますが、それらの間に多少の違いを導入することもできます。

すべての類似点を上位 (SetUp メソッドまたはヘルパー メソッド) に抽出すると、テストは見栄えがよくなり、テスト メソッドに残るのはそれらの間の違いだけになります。

于 2012-08-15T23:48:17.207 に答える