10

WCFサービスから予想される障害を単体テストするための最良の方法は何ですか？

特定の再現可能なエラーに対して（正しく）FaultExceptionsをスローしているWCFサービスの単体テストを試みています。単体テストは、WCFクライアントのインスタンスを取得し、FaultExceptionをスローする適切なサービスメソッドを呼び出します。

これらはすべて期待どおりに機能しますが、サービスの実装でエラーが検出されない場合、障害が原因でIDEが破損するため、これを単体テストするのが困難です。私は例外ではなく障害を使用しているため、IDEが例外をシリアル化してクライアントに送信し、そこで例外が発生することを期待していました。

特定のユーザー未処理の例外のブレークを無効にする構成オプションがあることはわかりますが、チーム環境では簡単に実行できないため、同じ結果を達成するためのより良い方法を誰かが指摘してくれることを期待していました。

これは、実装が現在どのように見えるかのサンプルコードです...

単体テストプロジェクトには、WCFサービスへのサービス参照があり、インターフェイスを次のように定義しました。

[OperationContract(Name = "DoSomething")]
[FaultContract(typeof(EpicFail))]
ResponseObject DoSomething(RequestObject requestObject);

障害は次のように定義されます。

[DataContract]
public class EpicFail
{

    public EpicFail(string action)
    {
        this.Reason = "Epic Fail";
        this.Action = action;
    }

    [DataMember]
    public string Reason
    {
        get;
        set;
    }

    [DataMember]
    public string Action
    {
        get;
        set;
    }

}

サービスを呼び出すコードは、漠然と次のようになります。

[TestMethod()]
[ExpectedException(typeof(FaultException<EpicFail>))]
public void FaultTest_Fails_Epicly()
{
    bool testPassed = false;

    try
    {
        ResponseObject resp = GetServiceClient().DoSomething(req);
    }
    catch (FaultException<EpicFail>)
    {
        testPassed = true;
    }

    Assert.IsTrue(testPassed);
}
  • コードを編集して、ExpectedException属性を使用していることを示しましたが、サービスで例外がスローされたときにIDE/デバッガーが壊れないようにする効果はあまりないようです。
4

2 に答える 2

1

mattv、

このテストでサービスにリモートアクセスする必要があるのはなぜですか？私があなたのコードを見たものから：

ResponseObject resp = GetServiceClient().DoSomething(req);

どういうわけか、サービスインスタンス自体ではなく、サービスクライアントを取得しています。単体テストでは、サービス具象クラスを直接テストすることをお勧めします。

ただし、このシナリオが必要な場合は、例外をキャッチせずにテストを実行してみましたか？同じ結果になりますか？

ちなみに、キャッチして再スローする必要がある場合は、次のパターンを使用してください。

try {
   //Do something
}
catch(SomeException e) {
   //Do something with e
   throw
}
于 2011-04-01T07:21:01.203 に答える
1

ExpectedExceptionAttributeこれがスローされた例外であることを確認するために、いつでも (NUnit で) を使用できます。MSTest にも同様の概念があります。

[ExpectedException(typeof(MyException))]
void my_test()
{
     // test
}

モック検証を行う必要がある場合は、try/catch ブロックを使用し、キャッチで検証してから例外をスローします。

アップデート

属性を使用している場合ExpectedException、例外をキャッチする必要はありません。代わりに、テストを実行する NUnit に例外をキャッチさせる必要があります。

例外の特別な情報を確認する必要がある場合は、例外をキャッチし、情報を確認してから再スローします。

[ExpectedException(typeof(MyException))]
void my_test()
{
     try
     {
         // call the service
     }
     catch(MyException ex)
     {
          Assert.IsTrue(ex.Message.Contains("error code 200"));
          throw ex;
     }

}
于 2010-11-01T17:16:03.497 に答える