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.
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.