.NET単体テストプロジェクトの組織
大規模な.netアプリケーションで単体テストを管理する最良の方法は何だと思いますか？ソリューション内の個別のプロジェクトごとにテストプロジェクトを追加するのか、それとも残りのプロジェクトのすべてのテストに1つの大きなテストプロジェクトを追加するのが良いですか。
たとえば、ソリューションに10個のプロジェクトがある場合、10個のテストプロジェクトを追加する方が良いですか、それともソリューション全体に対して1つの大きなテストプロジェクトで十分ですか？
モジュラーテストアセンブリにはいくつかの利点があることは知っていますが、テストカテゴリを使用してもかなり似たことが実現できます。多くのプロジェクトではコンパイルに時間がかかりますが、現時点で不要なプロジェクトを除外できます。一方、単一のプロジェクトがある場合は実行できませんが、コンパイルには少し時間がかかります。
回答のそれぞれの選択肢について、長所/短所を概説してください。
Phil Haackは、単体テストの構造化に関する素晴らしい記事を書きました。単体テストを書くとき、これは私の個人的なベストプラクティスになりました。これが彼の記事へのリンクです http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx
あなたの質問については、私は常に単体テスト用に別個のプロジェクトを作成し、それに.UnitTestsを追加して名前を付けます（単体テストと統合テストを区別するためにこれを行います）。たとえば、私のメインプロジェクトがSample.WebUIの場合、テストはSample.WebUI.UnitTestsになります。
ユニットテストがコンパイルに時間を追加することは事実ですが、私はマイナーな問題だと思います。私は17のプロジェクト（単体テストを除く）のソリューションに取り組んでおり、すべてをコンパイルするには約50〜60秒かかります。モニターから目を離し、変更のために何か他のものを見るのにちょうどいい時間です:-)
カテゴリについては、テストを迅速に完了する必要がある日次のビルドがある場合は、それらを使用して、完了するまでに時間がかかるテスト（統合テストなど）と区別します。また、TFSを使用している場合、カテゴリを使用すると、チェックインの自動化とテストに役立ちます。
個人的には、実際のプロジェクトごとに専用のテストプロジェクトを用意することを好みます。新しい機能/モジュール/プロジェクトを構築することになると、他の無関係なテストプロジェクトのスイートをすばやくフィルターで除外できるほうがはるかに優れています。これにより、TDDサイクルが非常に速くなり、開発中の新しいプロジェクトのテストをすばやく実行できます。
さらに重要なのは、無関係なコードを大量に散らかすことなく、必要に応じてフィクスチャのさまざまなテスト/モッククラスを適切に整理するのに役立ちます。また、関連するテストを新しい開発者が見つけやすくなります。最後に、特定のプロジェクトのテストの依存関係が、他の無関係なプロジェクトに誤って依存しないようにします。
私の個人的な選択は、ユニットテストのみのプロジェクトごとに1つのテストプロジェクトを用意することです。このテストプロジェクトのフォルダー構造は、テストするプロジェクトとまったく同じです。これらに加えて、必要な数の統合テストプロジェクトを作成します。
このアプローチの主な利点は、1つのプロジェクトを取得して別のソリューションで使用する場合、常にテストプロジェクトを一緒に使用して、新しいソリューションでチャンスを作らなければならない場合でも品質が維持されることです。
これまでのところ、1つのテストプロジェクトを使用する場合に参照を置き換える必要があること以外に、欠点を発見していません。
この質問を見てください： "ベストプラクティス：ユニットテストの整理"
問題のソリューションのサイズは異なりますが、そこに書かれたガイドラインはまだ有効です。