大型 Visual Studio 解决方案中的单元/集成测试组织
我开始为一个非常大的 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
- 硬件服务1
- 基础设施
- MyApp.Database.proj
- MyApp.Infrastruct.proj
- MyApp.ReportViewer.proj
- MyApp.SettingsManager.proj
- AppModules
- AppModule1.proj
- 常见
- 报告
- 服务
- ViewModel
- 观看次数
- AppModule2.proj（与其他 AppModule 的结构类似）
- AppModule3.proj（与其他 AppModule 的结构类似）
- AppModule1.proj
- 模块
- ComputeEngine.proj
- 页脚.proj
- 标题.proj
- CommonServices.proj
我的想法是创建一个名为“Tests”的解决方案文件夹，然后模仿上面的层次结构，为每个生产代码项目创建一个测试项目。在每个测试项目中，我都会创建名为“UnitTests”和“IntegrationTests”的文件夹。
我的重点是创建一致的命名/组织方案，以便新测试应该去哪里以及在哪里找到现有测试没有歧义。考虑到这个项目/应用程序的规模很大，我希望从一开始就使结构非常坚固，这样以后就不会感到痛苦了。
感谢您的时间和建议。
I'm starting to develop and organize tests for a very large Visual Studio solution. (Yes, I know that tests should have been developed along with the code rather than when the project is nearly complete, but things are what they are.)
I've seen similar questions about organizing unit tests in Visual Studio solutions, but I didn't see any that address integration tests as well. I would appreciate some guidance about where to place test projects so that they don't clutter up the already large code base.
Here's the basic hierarchy of things within the solution. (All items not ending in .proj are folders within a project or Solution Folders.)
- HardwareServices
- HardwareService1
- HardwareService1.Core.proj
- HardwareService1.Host.proj
- HardwareService1.Service.proj
- HardwareService2
- HardwareService2.Core.proj
- HardwareService2.Host.proj
- HardwareService2.Service.proj
- HardwareService1
- Infrastructure
- MyApp.Database.proj
- MyApp.Infrastructure.proj
- MyApp.ReportViewer.proj
- MyApp.SettingsManager.proj
- AppModules
- AppModule1.proj
- Common
- Reports
- Services
- ViewModels
- Views
- AppModule2.proj (similar structure to other AppModules)
- AppModule3.proj (similar structure to other AppModules)
- AppModule1.proj
- Modules
- ComputeEngine.proj
- Footer.proj
- Header.proj
- CommonServices.proj
My thought was to make a Solution Folder called "Tests" and then mimic the hierarchy above, making one test project for every production code project. Within each test project, I would make folders called "UnitTests" and "IntegrationTests".
My focus is to create a consistent naming/organization scheme so that there's no ambiguity about where new tests should go and where to find existing tests. Given the large size of this project/application, I'd like to get the structure pretty solid right out of the gate so that it's not a pain later.
Thank you for your time and advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们公司采用的命名约定是使用
projectName.Tests.Unit和projectName.Tests.Integration。根据您现有的结构，您将拥有如下所示的内容：
如果将测试文件夹与根文件夹一起保留，则不必再次模仿完整的结构，因为测试与相应的项目是正确的。
旁注
通过使项目名称具有一致的 Tests.Unit，它有助于在构建脚本中运行单元测试，因为您可以使用通配符搜索（如
**\*tests）运行测试.unit*.dll归根结底，项目结构可能非常主观，因此请做对您的环境有意义并且对您的团队有意义的事情。
The naming convention that our company adopted was the use of
projectName.Tests.UnitandprojectName.Tests.Integration.With your existing structure you would have something like this:
If you keep your tests folder along with the root folder you don't have to mimic the complete structure again as the tests are right with the respective project.
side note
By having the project name having a consistant Tests.Unit it helps assist in running unit tests in your build script as you can run tests with a wild card search like
**\*tests.unit*.dllAt the end of the day, project structure can be very subjective so do what makes sense in your environment and makes sense to your team.