現在、プロジェクト内のすべてのアセンブリに対してペアユニットテストアセンブリを作成しています。どちらも同じフォルダーにあります。
オープンソースプロジェクトを見ると、いくつかの小さなプロジェクトがすべてのテストを1つのアセンブリにまとめ、他のプロジェクトが私のように分割しているのを見てきました。私は大規模なソリューションを扱っているので、すべてのテストを1つのプロジェクトにまとめるのはかなりおかしいでしょう。
現在、すべての*.Test.csprojファイルでテストを実行するためのmsbuildロジックがあります。すべてのテストを別のフォルダーに置いていれば、これを行う必要はありません。
特定の方法で物事を行うための良い議論があるかどうか疑問に思っています。
ありがとう
同じ方法で行いますが、各テストプロジェクトのデフォルトの名前空間を、本番プロジェクトの名前空間と一致するように変更します。したがって、クラスのテストX.Y.FooはではX.Y.FooTestなく、で行われX.Y.Test.FooTestます。つまり、使用するディレクティブが少なくて済み、一般的に物事が簡単になります。
2つを別々のプロジェクトに保持したい主な理由は、本番ライブラリにテストを含めることや、テストされていないライブラリを出荷することを避けるためです。別のプロジェクト構造を使用すると、ビルドしたものすべてに対して単体テストを実行できます。また、（ライブラリの「感触」を取得するときに）2倍のファイルを参照しなくても、本番クラスだけを簡単に確認できます。
internal最後に、テスト時にメンバーにアクセスする必要がある場合は、常にが存在することを忘れないでください[InternalsVisibleTo]。
ユニットテストプロジェクトはできるだけ少なくすることをお勧めします。その理由は、作成するものごとに少なくとも10秒のコンパイル時間が追加されるためです。大きなプロジェクトでは、それは合計し始めます。
私が使用するディレクトリ構造は次のとおりです。
projectName / branchs / trunk / projects / code / codeproject1
projectName / branchs / trunk / projects / code / codeproject2
projectName / branchs / trunk / projects / code / codeproject3
projectName / branchs / trunk / projects / Tests / testproject1
projectName / branchs / trunk /依存関係projectName/プロトタイプ
projectName/..。
testproject1内では、次のディレクトリ構造があります。
codeproject1 /
codeproject2 /
codeproject2 / web
codeproject2 / web / mvc
codeproject3 /
codeproject3 / support
各プロジェクトが同じルートフォルダーの下の独自のフォルダーにあることを除いて、同じことを行います。次のようなもの：
ソリューションフォルダ
私は常にプロジェクトごとに個別のテストプロジェクトを持っています。その一部は、単にその構成が好きなことですが、他のソリューションで再利用できるように、ライブラリを独自のソリューションに分割することにした場合もよくあります。そのような場合、ライブラリプロジェクトに（単一のプロジェクト内のすべてのテストではなく）独自の個別のテストプロジェクトを持たせると、そのライブラリを簡単に分割できます。