Organization of Unit Tests in Visual Studio

Question

I'm currently creating a paired unit test assembly for every assembly in my project, both are in the same folder.

• MyProject/MyProject.csproj
• MyProject.Test/MyProject.Test.csproj

Looking at open source projects, I've seen some smaller project put all tests in one assembly, and other split it out like mine. I'm dealing with a large solution so it would be pretty crazy to put all tests in one project.

I currently have msbuild logic to run tests on all *.Test.csproj files. If I had all my tests in a different folder I wouldn't need to do this.

Just wondering if there are any good arguments to do things a certain way.

Thanks

Answer 1

I do the same thing except each project is in it's own folder under the same root folder. Something along the following:

Solution Folder

• ProjectA folder
• ProjectA.Test folder
• ProjectB folder
• ProjectB.Test folder

Answer 2

I do it the same way but I change the default namespace for each test project to match the namespace of the production project. So the tests for class X.Y.Foo are in X.Y.FooTest rather than X.Y.Test.FooTest - it means you need fewer using directives, and generally makes things simpler.

My main reason for wanting to keep the two in separate projects is to avoid either including the tests in the production library or having to ship an untested library. With the separate project structure, you can run unit tests against anything you build. It also makes it easier to look through just the production classes without having twice as many files to look at (when getting the "feel" of a library).

Finally, don't forget that if you need to access internal members when testing, there's always [InternalsVisibleTo].

Answer 3

I always have a separate test project for each project. Part of it is simply I like the organization of it, but I've also often run into situations where I've decide to break a library out into it's own solution so that it can be reused by other solutions. In those cases, having the library project have it's own separate test project (rather than all the tests in a single project) makes it much easier to break that library out.

Answer 4

I suggest making as few unit test projects as possible. The reason being is that each one you create adds on at least ten seconds of compile time. In a big project, it starts adding up.

Here's the directory structure I use:

projectName/branches/trunk/projects/code/codeproject1
projectName/branches/trunk/projects/code/codeproject2
projectName/branches/trunk/projects/code/codeproject3
projectName/branches/trunk/projects/Tests/testproject1
projectName/branches/trunk/Dependencies projectName/prototypes
projectName/...

and within testproject1, the following directory structure:

codeproject1/
codeproject2/
codeproject2/web
codeproject2/web/mvc
codeproject3/
codeproject3/support