単体テスト用に新しいプロジェクトを開始する必要がありますか? それは、2 つの実行可能ファイルが正しく取得されることを意味しますか? それから、名前空間の編成が気になります。別のプロジェクトの一部ですが、テストしているクラスと同じ名前空間に単体テストを配置できますか?
これは別の疑問を提起します。名前空間の命名規則が CompanyName.TechnologyName.Feautre.Design であることは知っています。ソリューション/プロジェクトのレイアウトでこれを正しく行うにはどうすればよいですか? ソリューション名＝会社名、プロジェクト名＝技術名ですか？
その場合は、単体テストを新しいプロジェクトに分離できないことを意味します。
最善の方法は、「本番プロジェクト」ごとに個別の単体テスト プロジェクトを作成することです。これにより、それらをペアで変更して移動できるようになります。
複数のターゲット プロジェクトをカバーする 1 つの単体テスト プロジェクトがある場合、これら 2 つのプロジェクト間に人為的な密結合が作成されます。これは、すべてのターゲット プロジェクトがないと単体テスト プロジェクトをコンパイルできないためです。これもまた、単一のプロジェクトを分離してテストすることを非常に困難にします。これが単体テストのすべてです。
単体テストを個別のライブラリに保持することは非常に重要です。これにより、コードのパブリック APIのみをテスト(ブラック ボックス テスト) できるようになります。
ターゲット名前空間の後に「UnitTest」を追加して、名前空間に名前を付けます。
私は、アセンブリごとに特定のテスト プロジェクト/アセンブリを使用する傾向があります。テスト アセンブリは、テスト対象のアセンブリと同じ名前に.Testなり、名前と名前空間に が追加されます。
こうすることで、テストを分離したままにしておくことができ、本番環境のコードと共にデプロイされることはありません。
フォルダーを含むソリューションごとに 1 つのテスト プロジェクト => ソリューション プロジェクト/フォルダー アーキテクチャを「ミラーリング」するサブフォルダーを持つ回帰/統合/ユニット。
覚えておいてください - テストは本番コードではありません。それらは分離する必要があります。
はい。単体テストは、独自の DLL にコンパイルされる別のプロジェクトである必要があります。
これは、プロジェクトと一緒にテスト コードを展開していないことを意味し、優れた設計を促進します (テストはプライベート/内部プロパティを参照できないため、他のシステムとやり取りするプロジェクトの一部をテストする傾向があります。内部実装のすべての詳細をテストすることに固執するのではなく)
ネーミングに関しては、通常、各プロジェクトの「コードネーム」を選択します - 現在のものはザンジバルと呼ばれています - そして最終的には次のようなプロジェクトになります:
MyCompany.Zanzibar.Website (ASP.NET MVC Web アプリケーション)
MyCompany.Zanzibar.Website.Testing (MVC Web アプリの単体テストを含む)
はい。ソリューション プロジェクトごとに単体テスト プロジェクトを作成します。
実行可能ファイルは 1 つだけです。単体テストは DLL で保持されます。
UnitTests関連する名前空間に' ' を追加しないでください。