ドメインオブジェクトへのWCF応答のユニットテスト翻訳

Question

WCFサービスから、複数のネストされたリストと多数のプロパティ（最大5レベルまで）で複雑な応答が返されます。この応答は1対1では使用できないため、UIで使用できるドメインオブジェクトに変換するトランスレータを構築しました。

翻訳プロセスをユニットテストして、フィールド間の不一致がないことを確認します。現在私のunittestsで私はコードで応答を構築しています。しかし、それはいくつかの仕事をやめてしまいました。特に、異なるフローをテストするために、さまざまなレスポンスにいくつかのバリエーションが必要な場合は特にそうです。また、unittestsは非常に大きなファイルになります。 （1つのレスポンスを構築するのは200行以上にすることができます）

私は、レスポンスをより簡単にして、私の単体テストをもっときれいに見せる方法を考えていました。

私が考えてきたオプションは、すべてのunittestに対して必要な応答を持つXMLファイルを作成し、これをレスポンスに逆シリアル化し、デシリアライズされたオブジェクトに対してunittestを実行することです。

この方法のプロは、ユニットテストがはるかに小さくなり、作成しやすくなるということです。しかし、ファイル/要素を更新するのは難しくなります。それとも少なくとも私が思うものです。

このレスポンス構築を簡単にするための考え方やオプションはありますか？

Answer 1

AutoFixtureなどのフレームワークを使用して、レスポンスのインスタンスを作成することができます。 AutoFixtureはプロパティを自動的に設定し、構築コードを非常に短くし、必要に応じてその動作を無効にすることができます。例：非カスタマイズされた値について

var mc = fixture.Build<MyResponseClass>() 
    .With(x => x.SomeProperty, "SomeValue") 
    .CreateAnonymous(); 

、Autofixtureはあなたが異なる値を毎回取得することが保証され、値を生成する決定論的ランダム性を使用していますが、まだ有効範囲内の値を維持します。

Answer 2

私は、あなたのレスポンスオブジェクトを作成し、それを別の* .dllにパックするというあなたの現在のコードを取ることを意味していると思っています。それはAPIまたはライブラリであり、単体テスト。したがって、単体テストはずっと簡単になります。 このアプローチのもう1つの利点は、実際には2つのAPI、つまり偽のオブジェクトを構築するAPIと実際のサービスを照会するAPIの2つを実際に構築できることです。インターフェイスを使用すると、簡単に設定を変更してAPIを切り替えることができます。 また、MoQやsmthのような模擬フレームワークを使用することもできます。それがあなたの場合に意味をなさないならば。

Answer 3

要求応答インターフェイスのテストを書くときは、可能な場合は、それぞれのケースが要求の最も重要な部分をテストするように、テストケースを書き込む必要があります。つまり、各テストケースは、一度に要求の重要な要素の1つをテストする必要があります。

あなたがこのパターンに従っている場合は、次のいずれかであるとして、各テストケースを識別することができる必要がありますすることができます

コアケース

から「ベース」を定義する場合他の試験が構築される。これらは常に、成功した要求を表す成功例です。単体テスト・クラスでコア・リクエストを定義したり、複数のコア・ケースがある場合は、共通ベースからコア・ケースを作成します。どちらの場合でも、これらのケースでは、値の「設定」の大部分を行っています。

偏差ケース

異なるユースケースをテストするための情報のいずれかを変更することにより、コアのテストケースをオフに構築されている場合。通常、これはあなたの最先端のケースであり、通常、予想される失敗（つまり、発信者が悪い情報を渡す）をテストします。

これは本質的にDRYになります。これは、コアケースがテストケースで「共通」なものを定義しているため、値を設定する200行を費やしていません。テストケース入力のほとんどは「<と同じですが、>と同じですが、<偏差>」と書かれている必要があります。