2

非常に簡単な質問があります。Context オブジェクトを持つコマンド オブジェクトにいくつかの単体テストを書いています。このコンテキストには、内部にいくつかのドメイン エンティティがあります。

    public class Context { 
          private DomainEntity domainEntity1;
          private Dto dto1;

          // getters and setters go here...

          public boolean isDomainEntityValid() {
              // a little bit of logic goes here
          }
    }

    public class Command {

          public void execute(Context context) { 
                // do its logic in here
          }
    }

DTO と DomainEntity には、セッターとゲッター、および非常に単純な検証メソッド ( などisFirstNameValid()) しかありません。

Context オブジェクトにはロジックが含まれています。結局のところ、コンテキストが一貫しているかどうか、コンテキストが完全かどうかなどをチェックします。

コマンド オブジェクトを単体テストするとき、コンテキストをモック アウトする必要があることは明らかですが、エンティティと dto はどうでしょうか。私はそれらを嘲笑する必要がありますか？もしそうなら、以下のような多くのコードを実行する必要があります

    doReturn(1L).when(domainEntity1).getId();
    doReturn("phil").when(domainEntity1).getName();

つまり、ゲッター メソッドの多くの動作を定義する必要があります。

要するに、オブジェクトの単体テストを行うときに、ドメイン エンティティと DTO をモックする必要がありますか?

4

2 に答える 2

2

あなたはおそらくここでデメテルの「法」に違反していると思います。これは法律としてではなく、アドバイスとして従うべきなので、引用符で囲みました。

具体的に何を変更する必要があるかを伝えるのに十分なコンテキストが提供されていません (つまり、コマンドに ID と名前が必要なのはなぜですか?) 。それに従うようにコードを変更すると、コードのテストがはるかに簡単になると考えてください。

于 2013-01-18T01:30:18.440 に答える
0

（私のコメントをもう少し詳しく説明できると思います）

モッキングなどを行う必要があるかどうかは、テスト対象のシステム (SUT、この場合はコマンド) のロジックによって異なります。

モック/スタブの全体的なアイデアは、SUT に対するテストが他の実際のコードに依存するものではないということです。したがって、テストでの使用に適したモック/スタブを作成するため、テストの有効性は SUT のみに依存し、他の実際のコードには依存しません (もちろん、モック/スタブが正しく記述されていることを前提としていますが、通常は問題ありません)シンプルなので）

したがって、 Command のロジックが次のようなものである場合

DomainEntity domain = context.getDomainEntity();
domain.doSomething();

はい、ドメインエンティティのモックを作成する必要があります。

ただし、次のように単にコンテキストに反して作業している場合:

if (context.isDomainEntityValid()) {
    doSomething();
} else {
    doAnotherThing();
}

その場合、ドメイン エンティティをモックする意味はありません。

もう 1 つ注意すべき点は、フレームワークのモックを使用して、SUT ロジックに従ってスタブを簡単に実行できることです。すべてのメソッドに対してスタブを行う必要はありません。

したがって、コマンドが を呼び出すだけの場合は、domain.doSomething()このメソッドをスタブするだけです。を忘れてくださいDomainEntity#anotherMethod() DomainEntity#getId()。

于 2013-01-18T03:25:11.150 に答える