DDDを実行するときにエンティティと値オブジェクトをモックする必要がありますか？

読んだ後、いくつかの 記事についてNewableを対注射のオブジェクトとどのようにこれらの概念は、DDDのサービス、エンティティと値オブジェクトに関連し、私は特に私のユニットテストで私のコードでnewablesの使用に関するいくつかの疑問が残りました。

Newableの主な候補は、EntitiesオブジェクトとValueオブジェクトでした。つまり、これらの依存関係を他のオブジェクトに注入する代わりにnew、これらのオブジェクトのインスタンスだけを作成して、コードで直接使用する必要があります。

ただし、適切なDDDプラクティスでは、エンティティと値オブジェクトに適切であると見なされた場合に責任を割り当てることを推奨しています。そのため、エンティティと値オブジェクトには、深刻なビジネスロジックが含まれなくなります。

ここで、サービスがエンティティまたは値オブジェクトで動作する場合、エンティティまたは値オブジェクトをモックしてサービスにモックを渡す必要があります（モックには、interface推奨されているように見える値オブジェクトまたはエンティティのが必要です）？

またはnew、エンティティ/値オブジェクトだけを具体的な実装をサービスに渡して、1つのユニットのみをテストするというユニットテストの原則に違反する必要がありますか？

ユニットテストは、SOLIDオブジェクトと同じように、「1つの理由で壊れる」必要があるとの意見です。それは高貴な目標ですが、多くの場合、それは単に実行不可能であることがわかるでしょう。これらのケースの1つは、テスト対象のシステムの依存関係である「リッチ」ドメインオブジェクト（DDDがエンティティと値オブジェクトを区別する、どちらも「ドメインモデル」を構成する）がある場合です。

このような状況で、私は、哲学持って与えられたがドメインオブジェクトには独自の包括的な単体テストカバレッジがあり、オブジェクトが別のSUTの単体テストで設計どおりに機能することは、必ずしも単体テストに違反するとは限りません。ドメインへの重大な変更が原因でこのテストが中断した場合、ドメインオブジェクトの単体テストも同様に中断し、調査の対象となることが予想されます。ドメインオブジェクトのユニットテストが赤のテストとして適切に更新され、変更によって緑になった後、この他のテストが失敗した場合も、必ずしも悪いことではありません。これは、この他のテストの期待がドメインの新しい期待と矛盾することを意味します。私は、両方がお互いに、そしてシステムの包括的な受け入れ基準に同意することを確認する必要があります。

したがって、ドメインオブジェクトがユニットテストの観点から望ましくない（つまり、データストアなどの外部リソースに触れる）「副作用」を生み出した場合、またはドメインオブジェクトのロジックが十分に複雑である場合にのみ、ドメインオブジェクトをモックしますテストに適した状態にすることは、テストを定義して合格するための障害となります。

それが運転の問題になります。どちらが簡単ですか？テスト内でドメインオブジェクトを本来の目的で使用するか、それを模倣するか。機能の変更によってサービスのテストが複雑な方法で中断される場合など、簡単なオプションがなくなるまで、どちらか簡単な方を実行します。これが発生した場合は、テストを書き直して、サービスに依存する機能要件を公開するモックを作成します。モックを壊すような複雑さはありません。

どちらの方法でも、実際のサービスにプラグインされた実際のドメインオブジェクトを使用して、これら2つの間の相互作用をより高い抽象度でテストする統合テスト（たとえば、サービスの背後にある機能だけでなく、エンドポイント、ただしドメインオブジェクトがシリアル化されて送信されるプロキシ）。

依存するクラスが適切に機能すると信頼し、何かが機能しないときに一部の単体テストが失敗することを期待して、非常によくテストする必要があります。多分いくつかの重要なユニットテストが欠けていますか？エラーが発生し、私の元のテストクラスで生成され、依存クラス自体でキャッチされない未テストのケースが存在する可能性があります。

したがって、単体テストについての私の意見では、依存クラスはモックされるべきです。そうしない場合は、統合テストです。