これには正解または間違った答えはありませんが、他の人がテストプロジェクトをどのように構築しているかを知ることは非常に役立ちますか？特に、マルチアセンブリソリューションと異なるテストフェーズ、ユニット、統合、システムを管理するためには？Visual Studioテストプロジェクトを構築するためのベストプラクティス
継続的インテグレーションサーバ（TeamCity）上でテストビルドを実行するためにどのような構造がうまく適合するかを知ることは役に立ちますか？
最初は私が出始めています：私は簡単に見つけることができるようにするために、別々のアセンブリ（x.Tests.dll、y.IntegrationTests.dll）の私のユニットテストと統合テストを保つ
Test (Namespace)
--Unit (Folder)
----ClassATests
----ClassBTests
--Integration (Folder)
----ClassA+BTests
----DBTests
私は今日この仕事について非常に考えています。私は過去に複数の人々によって維持され、更新されたテストプロジェクトを継承しました。そのようなプロジェクトには現在かなり混乱している階層が含まれています。私はそれがどんな時に実行されるコードのほとんどを手段として、これまでに便利に、このアプローチを見つけた
Tests (Namespace)
-- Infrastructure (Folder)
---- general utility classes (common to all tests)
---- any other config
-- ClassATests (Folder)
---- ClassATestBase (base class for setup of common mock objects etc.)
---- ClassATestMethods (helper methods for the ClassATests)
---- ClassATests (main test class)
-- ClassBTests (Folder)
etc.
：事項を簡素化する試みにおいて
は、私は次の構造を使用して開始しています与えられたテストは同じフォルダにあります。また、1つの巨大なTestMethodクラスのシナリオを避けることを目的としています。これは、ソリューションの中で最もエレガントではないかもしれません（申し訳ありませんが、意図されていません！）が、現在私のために働いています。どんな提案も大歓迎です！
ビルドプロセス中に実行するアセンブリをテストします。私は* .Tests.dllを見つけ出し、毎日のビルドの一部として実行することができます。統合テストは特定の環境で手動で実行されますが、依然として単純なビルドスクリプトから実行できます。
それ以外は、TestClass-per-Classは、私が1つのHelperTestsフィクスチャーからすべてテストされた小さなヘルパークラスであることを除いてほとんど例外なく続きました。