DDDを実行するとき、エンティティと値オブジェクトをモックする必要がありますか？
少数記事 についてNewablevsInjectableを読んだ後オブジェクトと、これらの概念がDDDのサービス、エンティティ、および値オブジェクトにどのように関連するかについて、コードでnewableを使用すること、特にユニットテストでnewableを使用することに疑問が残りました。
Newablesの主な候補はEntitiesオブジェクトとValueオブジェクトでした。つまり、これらの依存関係を他のオブジェクトに注入する代わりに、これらのオブジェクトのインスタンスをnewして、コードで直接使用する必要があります。
ただし、適切なDDDプラクティスでは、エンティティと値オブジェクトに適切であると見なされた場合に責任を割り当てることを推奨しています。そのため、エンティティと値オブジェクトには、深刻なビジネスロジックが含まれなくなります。
今度は、サービスがエンティティまたは値オブジェクトで動作する場合、エンティティまたは値オブジェクトをモックしてサービスにモックを渡す必要があります（モックには、反対するように思われる値オブジェクトまたはエンティティのinterfaceが必要です）？
または、エンティティ/値オブジェクトをnewにして具体的な実装をサービスに渡して、1つのユニットのみをテストするというユニットテストの原則に違反する必要がありますか？
ユニットテストは、SOLIDオブジェクトには「1つの理由で壊れる」必要があるように思われます。これは高貴な目標ですが、それらのケースの1つはここにあります。ここでは、「リッチ」ドメインオブジェクト（DDDはエンティティと値オブジェクトを区別します。エンティティと値オブジェクトはどちらも「ドメインモデル」を構成します）であり、テスト中のシステム。
これらの状況では、私は哲学を持っていますgivenドメインオブジェクトには独自の包括的な単体テストカバレッジがあり、オブジェクトが異なるSUTの単体テストで設計どおりに機能することは必ずしも違反しないと信じています単体テスト。ドメインへの重大な変更が原因でこのテストが中断した場合、ドメインオブジェクトのユニットテストも同様に中断し、何かを調査することにつながります。ドメインオブジェクトのユニットテストが赤のテストとして適切に更新され、変更によって緑になった後、この他のテストが失敗した場合も、必ずしも悪いことではありません。これは、この他のテストの期待がドメインの新しい期待と矛盾することを意味します。私は、両方がお互いに、そしてシステムの包括的な受け入れ基準に同意することを確認する必要があります。
したがって、ドメインオブジェクトがユニットテストの観点から望ましくない（つまり、データストアなどの外部リソースに触れる）「副作用」を生み出した場合、またはドメインオブジェクトのロジックが十分に複雑である場合にのみ、ドメインオブジェクトをモックします。テストに適した状態にすることは、テストを定義して合格するための障害となります。
それが運転の問題になります。どちらが簡単ですか？テスト内の意図した目的でドメインオブジェクトを使用するか、それを模倣するには？機能の変更によってサービスのテストが複雑な方法で中断される場合など、簡単なオプションがなくなるまで、どちらか簡単な方を実行します。これが発生した場合は、テストを書き直して、サービスに依存する機能要件を公開するモックを作成します。これにより、複雑さを壊すことはありません。
どちらの方法でも、実際のサービスにプラグインされた実際のドメインオブジェクトを使用して、これら2つの間の相互作用をより高い抽象度でテストする統合テスト（たとえば、サービスの背後にある機能だけでなく、エンドポイント、ただしドメインオブジェクトがシリアル化されて送信されるプロキシ）。
依存するクラスが適切に機能することを信頼し、何かが機能しないときにいくつかの単体テストが失敗することを期待し、これをテストする必要がありますvery vell。多分いくつかの重要なユニットテストが欠けていますか？エラーが発生し、元のテストクラスで生成され、依存クラス自体でキャッチされない未テストのケースが存在する可能性があります。
したがって、単体テストについての私の意見では、依存クラスはモックされるべきです。そうしない場合は、統合テストです。