.NETユニットテストプロジェクト組織

Question

大規模な.netアプリケーションで単体テストを管理する最良の方法は何でしょうか？ソリューション内の個別のプロジェクトごとにテストプロジェクトを追加するか、その他のプロジェクトのすべてのテストに対して1つの大きなテストプロジェクトを追加する方が良いでしょうか？

たとえば、ソリューションに10個のプロジェクトがある場合、10個の追加のテストプロジェクトを持つ方が良いか、1つの大きなテストプロジェクトでソリューション全体を十分に活用できますか？

モジュラテストアセンブリによって提供されるいくつかの利点があることは知っていますが、テストカテゴリを使用しても同様のことが達成できます。コンパイルには多くのプロジェクトで時間がかかりますが、必要のないプロジェクトはその時点で除外できますが、1つのプロジェクトでは実行できませんが、コンパイルには少し時間がかかります。

回答の選択肢ごとに長所/短所を説明してください。この質問に

Answer 1

Phil Haackは単体テストの構造に関する素晴らしい記事を書いています。これは私の個人的なベストプラクティスの単位テストを書くときになっています。ここに彼の記事へのリンクがありますhttp://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

私はいつも単体テストのための別のプロジェクトを作成し、ユニットテストと統合テストを区別するために.UnitTestsを付けて名前を付けます。たとえば、メインプロジェクトがSample.WebUIの場合、テストはSample.WebUI.UnitTestsになります。

単体テストではコンパイルに時間がかかるのは事実ですが、マイナーな問題だと思います。私は17プロジェクト（単体テストを除く）のソリューションに取り組んでおり、すべてをコンパイルするには約50-60秒かかります。

カテゴリに関しては、テストをすばやく完了する必要のある日常的なビルドがある場合は、それを使用して区別してください（統合テストのように）完了までに時間がかかるテストからまた、TFSを使用している場合、カテゴリを使用すると、チェックインを自動化してテストするのに役立ちます。

Answer 2

外観："Best Practice: Organize Unit Tests"

問題のソリューション・サイズが異なるが、そこに書かれたガイドラインはまだ有効です。

Answer 3

個人的には、私は実際のプロジェクトごとに専用のテストプロジェクトを持つことをお勧めします。新しいフィーチャ/モジュール/プロジェクトの構築に関しては、無関係の他のテストプロジェクトをすばやく除外できることがはるかに優れていることがわかりました。 TDDサイクルを非常に速くして、新しいプロジェクトのテストを素早く実行できるようにします。

もっと重要なのは、無関係なコードを混乱させることなく、必要に応じてさまざまなテスト/モッククラスの優れた構成を維持するのに役立ちます。また、新しい開発者が関連するテストを見つけるのがずっと簡単になります。最後に、特定のプロジェクトに対するテストの依存関係が、別の無関係のプロジェクトに誤って依存することがないようにします。

Answer 4

私の個人的な選択は単体テストでプロジェクトごとに1つのテストプロジェクトを持つことです。このテストプロジェクトのフォルダ構造は、テスト対象のプロジェクトとまったく同じです。これらに加えて、必要な数の統合テストプロジェクトを作成します。

このアプローチの主な利点は、1つのプロジェクトを別のソリューションで使用したい場合、常に新しいプロジェクトにチャンスを出さなければならないときにテストプロジェクトを一緒に使用することです。

これまでは、1つのテストプロジェクトを使用しているときに、参照を置き換える必要がなくなったということ以外は何も発見していませんでした。