Can you share the way you setup your unit test projects within your .net solutions?
I can imagine several possible methodologies. For example:
Having a separate solution for unit tests, perfectly mirroring the structure of the original code solution being tested.
Inside the original code solution, have a solution folder in which you're perfectly mirroring...
Have a unit test project for each code project and residing alongside it inside the solution's tree structure.
Have a unit test project covering several code projects residing alongside them in the tree structure.
Would love to hear how you're actually doing it in your solutions.
IMO, if you want to make your tests easy to run, the test project(s) absolutely must go in the same solution as the production code. While putting tests in another solution may work if all developers are extremely diligent, it adds an extra barrier between changing production code and running the tests. I tend to prefer removing as many barriers as possible.
There are a few different ways you can do it.
- A single test project per single solution (Product.UnitTests.csproj)
- A single test project per system (Product.SystemName.UnitTests.csproj)
- A one to one mapping of production projects and test projects (Product.ProjectName.csproj and Product.ProjectName.Tests.csproj)
Each has its own trade-offs you have to weigh up.
Single test project per single solution
Makes sense if the entire solution contains cohesive projects. If you are always going to be developing using the same solution, then it's nice to have a centralised test project.
It means there's a reduced overhead on your build process (when you have solutions with scores of projects, reducing the assembly count also reduces the build time) and there's no overhead of maintaining .nunit files or the like.
Also, everyone knows where the tests go. The downside is that you have to divide up different production projects by using namespaces, and the tests for one project are now tied into the others. I.e. this is the 'easiest' one to get buy-in for as there's less to keep track of and developers can easily run the tests. The downside is that in some cases this isn't a good fit for what you're developing.
Single test project per system
Basically the same as the above, except it's finer grained. You group related projects into areas / systems and use a single test assembly for each. This increases the complexity a little, but also means the systems are more easily extractable/re-usable in other solutions.
A one to one mapping of production projects and test projects
Has the most overhead in terms of creating new assemblies, increases the build times a bit when there's loads of projects and generally makes your solution file bigger. Requires diligence in terms of always keeping .nunit project files up to date and doesn't play so nicely with in-IDE unit testing.
The up-side is that maintaining a test project for each production project means that the tests are only dependent on the functionality they're testing (so it's easier to re-use projects) and you can more easily check code coverage by running one project at a time (whereas if you run all of your tests, you will get higher coverage due to unrelated tests sometimes touching code they're not interested in). Furthermore, it's a simple pattern to follow, so people will understand where the tests are meant to go without a problem.
In summary: I think any of the above can work well depending on what you're developing, but if you want a solution that 'just works', then I'd be inclined to go for the one to one mapping.
Definitely a single solution, but separate projects:
- You don't want your tests to be part of your production assembly (why add the bloat?)
- You don't want to have to switch between different solutions in order to switch between test code and production code; this can seriously break the rhythm in my experience. (I've been forced into this pattern once, and it was horrible.) It also breaks refactoring - if you change a method in your production code, you want tests to automatically use the new method name. (Admittedly the names of some tests may need to be changed manually.)
One test project per production project works well for me. I tend to make the namespace the same for both tests and production code, which means you typically don't need as many using directives.
The following structure has worked well for me. It also keeps the production and test code separate.
\source
\source\code\MainSolution.sln
\source\code\Project1
\source\code\...
\source\test\TestSolution.sln
\source\test\TestProject1
\source\test\...
Have the same solution for both, but 2 projects, the .NET project and the NUnit project (One to One), now if I have a solution that have multiple projects, then I have just 1 NUnit project for the solution as it and 1 for each project.. I think is a good way because it serves me to mantain organized my projects.
Also, you can take a look at this book: http://www.artofunittesting.com/ it's very good.
I prefer to have a test project in the same solution as my source code and I group tests by adding folders
