時々、私はさまざまなアプローチを見ます：
誰かが現在テストしている同じプロジェクトに unittest を保存し、プロジェクトのルートの下に test フォルダーを作成するだけです。
テストするソリューションから、プロジェクトごとに追加のテスト プロジェクトを作成する人がいます。
誰かが、ソリューション全体のすべてのテストに対して 1 つの大きなテスト プロジェクトを持っています。
では、テストを .NET の世界に保存するための一般的な、つまり "公式" の方法とは何でしょうか? マイクロソフトがそのためのガイドラインを持っていることを確信してください。
テスト コードの第 1 のルール: テスト コードを製品アセンブリ (成果物) 内に決して入れないでください。
このルールの理由は単純です。テスト コードは、オンサイト インストールを破損する可能性があるからです。優れたコーディング慣行があっても。優れたプログラマーであっても。
テストコードの第 2 のルール: プログラマー自身が保守する必要があります: 開発者がコードをリファクタリングする場合、テストコードもそれに合わせて変更する必要があります。したがって、何らかの方法で回避できる場合は、別のソリューションに入れないでください。
ここから先はあなた次第です。個人的には、製品アセンブリとテスト アセンブリをほぼ 1 対 1 で対応させ、名前に「.Test」を追加することを好みます。
次に、このネーミングを使用して、製品アセンブリの csproj ファイルで単体テストを行うときにそれらを除外します。
ああ、本番アセンブリにテスト コードを入れてはいけないと言いましたか?
この質問は少し主観的であるように思われるため、多数の回答が得られる可能性が高く、最終的には、あなたとチームにとって何が最適かを判断するのはあなた次第です。
私の $.02 ...
私は通常、テスト対象のコードとは別のプロジェクトでテストが行われることを期待しています。これにより、結果として得られるアセンブリが肥大化するのを防ぎ、テスト コードを運用環境にデプロイする (または目的に応じてクライアントに配布する) 必要がなくなります。
テストを同じプロジェクトに含めるか、複数のプロジェクトに分散するかは、作成するテストによって異なります。テストがすべて関連していて、それらをまとめてバンドルすることが理にかなっている場合は、それらを 1 つのプロジェクトに入れますが、あまり関連性がない場合は、それらを同じプロジェクトに入れる理由がわかりません。
この判断は、どのコードでも同じようにテストに適用できると思います。合うなら合わせる、合わないならしない。
テストを書いているということは、おそらく正しい道を進んでいるということです。ですから、何かを試してみることを恐れないでください。うまくいくかどうかを判断し、うまくいかない場合は、別の方法で試してみてください。コードを書くことの利点は、ニーズに合わせて時間をかけてリファクタリングできることです。:)
これは私が見たものです
a) 専任の QA チームが独立してテスト コードを管理する大規模なチームでは、独自のソリューションでテスト コードを管理する方が簡単です。
b) 開発者が単体テストといくつかの機能テストを推進する大規模なチームではないため、同じソリューションの一部としてテストを管理することが容易になります。
c) そして今日、TDD がより積極的に採用されているため、テストを製品コード プロジェクト自体の一部として単純に持つことが容易になっています。
ガイドラインは、テストを管理するのに最適な場所にテストを配置することであり、今日のほとんどの人にとって、通常は a または b のいずれかになります。
UT: http://msdn.microsoft.com/en-us/library/hh598957.aspx
TDD: http://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx