6

我开始为一个非常大的 Visual Studio 解决方案开发和组织测试。（是的，我知道测试应该与代码一起开发，而不是在项目接近完成时进行，但事情就是这样。）

我已经看到有关在 Visual Studio 解决方案中组织单元测试的类似问题，但我也没有看到任何解决集成测试的问题。我会很感激一些关于在哪里放置测试项目的指导，这样它们就不会弄乱已经很大的代码库。

这是解决方案中事物的基本层次结构。（所有不以 .proj 结尾的项目都是项目中的文件夹或解决方案文件夹。）

  • 硬件服务
    • 硬件服务1
      • HardwareService1.Core.proj
      • HardwareService1.Host.proj
      • HardwareService1.Service.proj
    • 硬件服务2
      • HardwareService2.Core.proj
      • HardwareService2.Host.proj
      • HardwareService2.Service.proj
  • 基础设施
    • MyApp.Database.proj
    • MyApp.Infrastructure.proj
    • MyApp.ReportViewer.proj
    • MyApp.SettingsManager.proj
  • 应用模块
    • AppModule1.proj
      • 常见的
      • 报告
      • 服务
      • 视图模型
      • 意见
    • AppModule2.proj（与其他 AppModule 类似的结构）
    • AppModule3.proj（与其他 AppModule 类似的结构）
  • 模块
    • 计算引擎.proj
    • 页脚项目
    • 头文件.proj
    • CommonServices.proj

我的想法是制作一个名为“Tests”的解决方案文件夹，然后模仿上面的层次结构，为每个生产代码项目制作一个测试项目。在每个测试项目中，我会创建名为“UnitTests”和“IntegrationTests”的文件夹。

我的重点是创建一个一致的命名/组织方案，以便在新测试应该去哪里以及在哪里找到现有测试方面没有歧义。鉴于这个项目/应用程序的规模很大，我希望结构非常坚固，这样以后就不会痛苦了。

感谢您的时间和建议。

4

1 回答 1

5

我们公司采用的命名约定是使用projectName.Tests.Unit和projectName.Tests.Integration。

使用您现有的结构，您将拥有如下内容：

  • 硬件服务1
    • 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 回答