大規模な .net アプリケーションで単体テストを管理する最良の方法は何だと思いますか? ソリューション内の個別のプロジェクトごとにテスト プロジェクトを追加するのと、残りのプロジェクトのすべてのテストに対して 1 つの大きなテスト プロジェクトを追加するのとではどちらがよいでしょうか?
たとえば、ソリューションに 10 個のプロジェクトがある場合、10 個の追加のテスト プロジェクトを用意した方がよいでしょうか?それとも、ソリューション全体に対して 1 つの大きなテスト プロジェクトで十分でしょうか?
モジュール式のテスト アセンブリによっていくつかの利点が得られることはわかっていますが、テスト カテゴリを使用してもほぼ同様のことが実現できます。多くのプロジェクトではコンパイルに時間がかかりますが、その時点で不要なプロジェクトを除外することはできますが、プロジェクトが 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 つのテストプロジェクトを使用する場合よりも多くの参照を置換する必要があること以外に、欠点を発見しませんでした。