6

非常に大規模なVisualStudioソリューションのテストの開発と整理を始めています。（はい、プロジェクトがほぼ完了したときではなく、コードと一緒にテストを開発する必要があることを私は知っていますが、物事はそれらが何であるかです。）

Visual Studioソリューションでの単体テストの編成について同様の質問を見てきましたが、統合テストに対応する質問も見当たりませんでした。すでに大きなコードベースを乱雑にしないように、テストプロジェクトを配置する場所についてのガイダンスをいただければ幸いです。

ソリューション内の基本的な階層は次のとおりです。（.projで終わらないすべてのアイテムは、プロジェクト内のフォルダーまたはソリューションフォルダーです。）

  • HardwareServices
    • HardwareService1
      • HardwareService1.Core.proj
      • HardwareService1.Host.proj
      • HardwareService1.Service.proj
    • HardwareService2
      • HardwareService2.Core.proj
      • HardwareService2.Host.proj
      • HardwareService2.Service.proj
  • インフラストラクチャー
    • MyApp.Database.proj
    • MyApp.Infrastructure.proj
    • MyApp.ReportViewer.proj
    • MyApp.SettingsManager.proj
  • AppModules
    • AppModule1.proj
      • 一般
      • レポート
      • サービス
      • ViewModels
      • ビュー
    • AppModule2.proj（他のAppModuleと同様の構造）
    • AppModule3.proj（他のAppModuleと同様の構造）
  • モジュール
    • ComputeEngine.proj
    • Footer.proj
    • Header.proj
    • CommonServices.proj

私の考えは、「テスト」と呼ばれるソリューションフォルダーを作成し、上記の階層を模倣して、本番コードプロジェクトごとに1つのテストプロジェクトを作成することでした。各テストプロジェクト内に、「UnitTests」および「IntegrationTests」というフォルダーを作成します。

私の焦点は、新しいテストをどこに置くべきか、そして既存のテストをどこで見つけるかについて曖昧さがないように、一貫した命名/編成スキームを作成することです。このプロジェクト/アプリケーションのサイズが大きいことを考えると、後で苦痛を感じないように、構造をゲートからすぐにしっかりと整えたいと思います。

お手数をおかけしますが、よろしくお願いいたします。

4

1 に答える 1

5

当社が採用した命名規則は、projectName.Tests.Unitとの使用でしたprojectName.Tests.Integration。

既存の構造では、次のようになります。

  • HardwareService1
    • HardwareService1.Core.proj
    • HardwareService1.Host.proj
    • HardwareService1.Service.proj
    • テスト
      • HardwareService1.Core.Tests.Unit
      • HardwareService1.Core.Tests.Integration

テストフォルダをルートフォルダと一緒に保持する場合、テストはそれぞれのプロジェクトで正しいため、完全な構造を再度模倣する必要はありません。

サイドノート

プロジェクト名に一貫性のあるTests.Unitを含めることで、次のようなワイルドカード検索を使用してテストを実行できるため、ビルドスクリプトでユニットテストを実行するのに役立ちます。**\*tests.unit*.dll

結局のところ、プロジェクトの構造は非常に主観的なものになる可能性があるため、環境で意味があり、チームにとって意味のあることを実行してください。

于 2011-09-08T15:48:29.600 に答える