Question

I am going back and forth with my team on this and wanted to get some opinions form the community.

Currently, in TFS our structure is like this:

{Main Project Root}
     Development
          Branches
          Trunk
              Source
                 Data Access Layer
                      {Holds Solution for DAL}
                 UI Layer
                      {Hold Solution for UI}
                 Business Layer
                      {Holds Solution for BL}
          Documentation
          Tests
               Data Access Layer
                    {Holds solution for DAL Tests}
               UI Layer
               Business Layer
     Integration
          Source
               Data Access Layer
               UI Layer
               Business Layer
          Tests
               Data Access Layer
               UI Layer
               Business Layer

We are mimicking the source structure in our Test folder in TFS. Now, when it comes to our VS 2010 solutions, is it s good idea to bundle our test solutions inside our Source solutions?

So, Let’s say inside my DAL solution I have this:

Dal Solution
     {Solution Folder DAL}
          {Projects For Solutions}
     {Solution Folder For Tests}
          {Projects for Tests}

Another thought is to keep the UTs by themselves and not bundle them with the source solutions.

What are other in the community doing to organize their Tests and solutions?

Answer 1

Without having directly a very strong argumentation for it, we like to have the unittest next to the actual unit it tests as closely as possible. So a pure DAL unittest is in the DAL solution as you describe.

Then for integration test that span multiple modules in the same architectural layer we put that next to the modules in, inside that layer. Consequently, Coded UI test (system level testing) and integration test that span multiple architectural layers are put at the highest level next to the layers in the solution structure.

The benefit of this approach is that the tests are always located as close to what they test as possible, without violating the solution pattern. This allows to have the namespace of the unittest also follow the namespace schema of the production code.