Menu
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.)
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.
543
Challenges in Integration testingDifficult to perform – It is very difficult to perform as compared to system testing in which we can consider the application as a black box. Time-consuming – It is very time-consuming and resource-intensive to test all the interfacing between the different connected modules.
Put Unit tests in the same project as the code to achieve better encapsulation. You can easily test internal methods, which means you wont make methods public that should have been internal.
The naming convention that our company adopted was the use of projectName.Tests.Unit and projectName.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*.dll
At 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.
171
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
