大型 Visual Studio 解决方案中的单元/集成测试组织

Question

我开始为一个非常大的 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 的结构）
• 模块
  • ComputeEngine.proj
  • Footer.proj
  • Header.proj
  • CommonServices.proj

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

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

感谢您的宝贵时间和建议。

Answer 1

我们公司采用的命名约定是使用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

归根结底，项目结构可能非常主观，因此请按照对您的环境有意义且对您的团队有意义的方式进行。