ソリューションのプロジェクトをテストする

StackOverflow https://stackoverflow.com/questions/269730

質問

.NETでは、単体テストプロジェクトを他のソリューションと共に配置する必要がありますか？または、すべてのテストプロジェクトを収容するテストソリューションが必要ですか？

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

通常は何をしますか？

役に立ちましたか？

解決

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

これまでのマイナス面は、ユニットテストがアプリケーションコードの特定のメンバー（保護されたものと内部のもの）に到達できない場合がありましたが、通常はデザインが改善される可能性があることを発見することになります。

そして、同様のスレッドを指摘する必要があると思います

他のヒント

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

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

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

これは、ユニットテストコードが明示的な参照もテストすることを（参照を使用して）確実にできることを意味します（何かが同じアセンブリにあるために暗黙のうちに何らかの可視性を取得するのではなく、たとえば＆quot; Internal＆quot;）

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

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

。ユーザーはそのようなものを必要とせず、必要とさえしません。

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

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

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

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

所属していません StackOverflow
scroll top