タグ付けされた質問 「tdd」

私のチームと私が取り組んでいるプロジェクトでは、大きな足場のコードが必要になることがよくあります。正しい値を持つドメインオブジェクトの作成、リポジトリのモックの設定、キャッシュの処理などは、すべてのテストで一般的に発生することです。多くの場合、ドメインの中心となる同じ基本オブジェクト（人、...）で作業しているため、他のオブジェクトで作業するために、多くのテストでこれらのオブジェクトのインスタンスが作成されます。基本ドメインを使用するさまざまなソリューションがたくさんあるので、この種のコードは多くの場合、それらのソリューションに分散しています。 私はこの足場の多くを行う共通のクラスを作成することを考えてきました。これにより、すべてが設定された完全にインスタンス化された人（リポジトリ経由のアクセス、キャッシングなど）をリクエストできます。これにより、個々の単体テストから重複したコードが削除されますが、テストごとに「多すぎる」コードが大量にあることも意味します（必要なパーツだけでなく、完全なオブジェクトが設定されるため）。 誰かこれをしたことがありますか？このアプローチを検証または無効にする可能性のある洞察、発言、考えなどはありますか？

8 unit-testing  tdd 

多くのスレーブエンティティで構成されるマスターと呼ばれるエンティティがあります。 データベースに存在できるマスターは1つだけであり、リポジトリーを照会して、指定されたIDのスレーブを取得します。 最初にSlaveRepositoryを作成し、それをIDでクエリしました。それは問題なく機能し、他の開発者が私のリポジトリを使用できます。 次に、集約ルートについて考え、MasterRepositoryを作成してマスターを返し、それに対してループを実行して、必要なスレーブエンティティを取得しました。私がここで感じた問題は、これを他の開発者に公開すると、同じようにする必要があるため、GetSlaveByID（string id）と呼ばれるMasterRepositoryのメソッドを使用して、スレーブを直接取得できます（ループ機能を非表示にします） ）。 さて、私のリポジトリはMasterRepositoryと呼ばれていてもスレーブを返す必要がありますか？そしてもっと重要なのは、どちらが正しい道なのか？ 私はDDDとTDDを適用しようとする初期段階にあるので、どちらが正しい方法であるかを判断する前に、おそらく多くのことを検討する必要があります。

8 architecture  tdd  domain-driven-design