.net - ソリューション内のプロジェクトをテストします

Question

.NET では、ユニット テスト プロジェクトを残りのソリューションと共に配置する必要がありますか? それとも、すべてのテスト プロジェクトを収容するテスト ソリューションが必要ですか?

すべてのテスト プロジェクトがコード ベース ソリューションに含まれていますが、少し面倒です。

普段何をしていますか？

Answer 1

現在のプロジェクトでは、すべての単体テストを別々のプロジェクトに入れることにしました。アプリケーション コードとテストは同じソリューションにありますが、少なくとも、単体テスト コードのないバージョンをビルド (およびデプロイ) できます。

これまでのところ、これのマイナス面は、ユニット テストがアプリケーション コードの特定のメンバー (保護されたものと内部のもの) に到達できない場合があることでしたが、通常は、設計を改善できることがわかりました。

そして、同じ/類似のトピックに関するより多くの回答がある同様のスレッドを指摘する必要があると思います。

Answer 2

私は常にそれらを解決策の一部として保持してきました-結局のところ、それらは解決策の一部です. ただし、プロジェクトを表示するためのさまざまなアプローチに対して複数のソリューションを使用できるため、場合によってはテストレス ソリューションを作成することをお勧めします。

Answer 3

通常、単体テストを独自のプロジェクトに配置し、統合テストをアプリケーション ソリューション内の独自のプロジェクトに配置します。

私が働いている場所では、Web テストを別のソリューションに入れることを検討しています。Web テストのオーサリングを QA チームと共有する予定であり、これらのテストがビルドの責任になることを望んでいません。

Answer 4

テスト コードは出荷されませんが、ソリューション全体の一部です。私たちのビルダーは、テスト アセンブリとコア コンポーネントを分離します。ソリューション管理の観点からは、140 以上のプロジェクトを持つソリューションは圧倒されるように思えます。

Answer 5

同じソリューション内で常に別のプロジェクトを使用します。

これは、ユニットテストコードが明示的な参照もテストすることを (参照を使用して) 確信できることを意味します (同じアセンブリ内にあるために何かの可視性を暗黙的に取得するのではなく、たとえば「内部」)。

Answer 6

私は .NET を使用しませんが、あらゆる種類のテスト ケースを開発するときは、テストなしでアプリケーションを展開できるように、残りのコードからそれらを分離しておきます。ユーザーはそのようなものを必要としないか、望んでさえいません。

Answer 7

プロジェクトのデザインを見てください。MVC レイアウトまたはその代替のいずれかに近い場合は、異なるアセンブリの異なるレベルが必要です。設計のレベルごとに 1 つのテスト サブアセンブリを作成します。

テスト プロジェクトは通常、EXE を作成するプロジェクトの代わりに実行されます。私たちの EXE プロジェクトは、イベントと情報をコントローラー クラスで満たされたアセンブリに渡すシン シェルです。このアセンブリには、ほとんどの人が EXE プロジェクトに入れるコードがあります。これにより、テスト プロジェクトは、通常のテスト プロセスの 90% で EXE のふりをすることができます。

実際のテスト ケースに最適な配置を検討中です。現在、フレームワーク ユーティリティ、アプリケーション オブジェクト、UI フレームワーク、コマンド、UI コントローラー、および EXE の主要なレベルがいくつかあります。EXE (手動でテストされます) を除いて、レベルごとに 1 つのアセンブリがあります。アセンブリを編集すると、そのレベルのテスト アセンブリが読み込まれます。すべてのレベルに関係する何かを行う必要がある場合、すべてのテスト アセンブリをロードする必要があります。

ワンボタン ビルド プロセス中に、テスト プロジェクト exe を実行します。(これには別のユーティリティがあります)。