私は少し混乱しています。異なるアセンブリでユニットテストの対象となるプロジェクトを手に入れました。共同開発者は別のプロジェクト+別のユニットテストアセンブリも作成しました。ここでは、ユニットテストプロジェクト（オブジェクトファクトリ、初期化タスク、注入/擬似ヘルパーなど）の間でいくつかのロジックを混在させたいと考えています。そうすれば、彼のプロジェクトはアセンブリを参照することになります。ベストプラクティス：Unit Test Structuring
私は、すべてのプロジェクト（1回目のテストでは2回目、2回目では統合テストが含まれる）の1つの単位テストアセンブリを表す視点を見つけました。これは正しい方法ですか？もしそうでなければ、単体テストの共有ロジックをどこに置くべきでしょうか？
確かに異なるアプローチがありますが、単一の「正しい方法」はありません。これはテストの構造です：
当社製品には、いくつかのアセンブリで構成される「モジュール」があります。それぞれの「モジュール」には、1つの単体テスト・アセンブリと1つの統合テスト・アセンブリがあります。我々はこのように他の人からテストアセンブリを参照しています：
「モジュールX」テストでは、「モジュールY」テストは決して参照されません。
単体テストを別々のアセンブリに配置する理由は、テストコードとプロダクションコードが混在しないようにするためです。アセンブリは心配の明確な分離を提供し、必要でないときにテストを削除するのに十分な柔軟性を提供します。例えば。あなたがリリースするとき、最終顧客は、最終結果を使用したいときだけ、すべてのテストコードをダウンロードすることには興味がありません。
多くのテストアセンブリ（各 "実際のコード"アセンブリに1つ）を持たせることについてはまったく問題がありません。テストアセンブリ間で参照を追加することはそれほど難しくありません。実際にはアセンブリ間の参照（つまり依存関係）を必要としないので、実際にコードをあまり混乱させないようにします。
また、単体テストではあまり論理を共有しないようにしてください。単体テスト/模擬/ DIフレームワークのためです。テストコードにカスタム実装のファクトリをたくさん持つことは、プロダクションコードを必要以上に複雑にしてしまったという良い指標です。
私を説得する必要はなく、テストアセンブリは別々にする必要があります。しかし、応答に感謝します。 –
同様の状況があります。私の仲間が同意するならば、私はあなたの答えを受け入れたものとしてマークします。 :) –