2

Approveというメソッドを持つOrderクラスがあるとします。このメソッドが呼び出されると、特定の条件がチェックされ、注文が承認済みの状態になるか、例外がスローされます。サービス層では、次のようなものがあります。

var order = _repository.Single(o => o.ID == orderID);
order.Approve();
_context.SaveChanges(); // or _session.SaveChanges();

この方法をテストするには 2 つの方法があります。これに関するご意見をお聞かせください。

解決策 1 : リポジトリをスタブ化して Order オブジェクトを返します。次に、注文が「承認済み」の状態であることを表明します。

解決策 2 : リポジトリをスタブして、Mock Order オブジェクトを返します。Approve() メソッドが呼び出されたことをアサートします。

解決策 1 の方が簡単です。個人的には、対話ベースのテストよりも状態ベースのテストを好みます。後者は実装の詳細を対象とする可能性があるため、避けるべきです。ただし、指定された注文が承認済みの状態であることをテストすることは、このサービス メソッドの関心事ではないと思います。例外がスローされたかどうか、または注文の状態が承認済みに変更されたかどうかをテストするには、Order クラス用の別のテスト メソッドが必要だと思います。

解決策 2 は、注文を承認する責任を Order クラス自体に委任しているため、論理的に聞こえるかもしれません。したがって、このサービス メソッドにはおそらく 2 つのテストが必要です。1 つは注文の承認タスクを Order クラスに委譲することを確認するテストで、もう 1 つは変更を保存することを確認するテストです。

これについてのあなたの洞察は何ですか？あなたはどのソリューションを好みますか？

乾杯

4

1 に答える 1

5

単体テストは、観察された動作が期待/仕様に準拠しているかどうかをテストすることです。

あなたの質問への答えは、この場合の「予想される動作」と考えられるものに要約されます。b)期待される動作が承認アクションの委任である場合は、メソッド呼び出しをテストします。

いずれの場合も、オブジェクトの動作もテストする必要がありOrderます (呼び出しApprove()によって状態が承認済みに変更されるようにするため)。

2 番目の解決策は、2 つのオブジェクトの動作を分離するのでうまく機能しますが、注文が承認済みの状態になる方法が複数ある場合 (それがテスト対象です -- ケース a))、受け入れられるものを制限します。不必要な振る舞い。

また、承認部分に必須でない場合は、保存部分をテストするための別のテストを作成します

于 2012-05-28T01:01:20.750 に答える