How best to organize projects folders for unit tests in .NET?

Question

So I'm trying to introduce unit testing to my group. I've successfully upgraded a VS'05 web site project to a VS'08 web application, and now have a solution with the web app project and a unit test project.

The issue now is how to fit this back into the source repository such that we don't break the build system and the unit test projects are persisted as well.

Right now we have something like this:

c:\root
c:\root\projectA
c:\root\projectB
c:\root\projectC

where projectA contains the sln file and all other related files/folders for the project.

Now I have this new solution that looks like this:

c:\root\projectA (parent folder)
c:\root\projectA\projectA (the production code project)
c:\root\projectA\projectA_Test (the unit test project)
c:\root\projectA\TestResults
c:\root\projecta\projectA.sln

How do I integrate this new structure back into the code repository?

I'd really prefer to keep the production code folder where it was in the source repository for the sake of the build, but is this necessary? If I keep the production code project in its usual place then where do I keep my unit test projects and how do I connect them with a sln file?

Is it better to use this new structure and adjust the build process?

I'd love to hear how other people are dealing with this issue of upgrading legacy projects to unit testing.

Answer 1

For the last 12 years we took a simple approach to structuring files, source control and software build and release process. We try to keep all the solution parts under one solution. We chose Nunit to create our unit tests.

• SolutionA\Business.proj
• SolutionA\Business.Nunit.proj
• SolutionA\Business.Nunit.proj\TestResult\ResultsYYYYMMDD.xml
• SolutionA\GUI.proj
• SolutionA\MSI.proj

Initially all we did with our GUI projects that contained all the business logic we want to unit test was to move it to the Business project (class project). At the same time we created the Business.Nunit.proj that just references the Business.proj but uses the Nunit GUI as the startup. This way we don't release software with any unit test code in it.

Eg.

• Start External Program: C:\Program Files\NUnit 2.5.2\bin\net-2.0\nunit.exe
• CommandLine: Business.Nunit.dll

During source control checkin we run a continous build process (Final Builder) the automatically executes the Nunit tests and emails failures back to the developers. Final Builder also have a web site that gives a graph of build failures, so you can see how your going visually.

When it comes to shared class libraries, all the nunit tests for this are located in that solution so we know it works, then we use source control to share an edition of the library to our solution/project. This makes it easy to identify the shared components used and the edition used. Shared libraries also get inserted into source control to make it easy to distribute them.

Eg.

• Solution\Project\Shared\Components\ClassLibrary1.0.0.0\

In source control we use source control labels for all minor software editions, but a major edition to branched to a new directory. Major edition general involve significant code movement that makes it pointless to compare to previous editions.

E.g.

• Solution\Projectv1\
• Solution\Projectv2\

If you have a software consultancy then you might also separate projects out above this.

Eg.

• Customer\SolutionA
• CustomerB\SolutionA
• CustomerB\SolutionB

I wouldn't company departments in the source control path because they change too much over time.

Physical Files

The structure of our source control vs the physical file structure differs slightly.

On the Server

• *\SolutionA\Data
• *\SolutionA\Documents
• *\SolutionA\Database
• *\SolutionA\Version1.0.0.0\Build
• *\SolutionA\Version1.0.0.0\MSI
• *\SolutionA\Version1.0.0.0\Source
• *\SolutionA\Version1.1.0.1234...

On the Build Server (including unit testing)

• *\SolutionA\Source
• *\SolutionB\Source

On the Developers workstation

• *\Customer\SolutionA\Source
• *\Customer\SolutionB\Source

Note: You want to keep the developers and build machine data structure matching to make it easier for developers to automate software builds themselves if needed. Having an explicit \Source* directory allows the automated builds to be placed in the root of the Solution\Project folder.