.NET unit testing projects organisation

Question

What would you say is the best way to manage the unit tests in a large .net application? Is it better to add a test project for each separate project in the solution or one large tests project for all the tests in the rest of the projects?

For example if there are 10 projects in a solution, is it better to have 10 additional test projects or one large tests project would suffice for the whole solution?

I know there are some benefits offered by modular test assemblies, but pretty similar things can be achieved using tests categories. Compilation takes longer with many projects, but you can exclude the projects you don't need at that moment, while if you have one single project you can't do that, but the compilation takes a little bit less time.

Please outline advantages/disadvantages for each choice in your answers.

Answer 1

Phil Haack wrote a nice article regarding the structuring of unit tests. This has become my personal best practice when writing unit tests. Here is the link to his article http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

As for your question, I would always create a separate project for unit test and name it with .UnitTests appended (I do this in order to distinguish between unit and integration tests). For example, if my main project is Sample.WebUI, the test will be Sample.WebUI.UnitTests.

It is true that unit tests add additional time to the compilation, but I consider that a minor issue. I am working on a solution with 17 projects (excluding unit tests) and it takes about 50-60 second to compile everything. It is just about enough time to take my eyes off the monitor and look at something else for a change :-)

Regarding the categories, if you have some daily builds that require tests to complete quickly then use them and distinguish them from those tests that take longer to complete (like integration tests). Also, if you are using TFS, using categories can help automate and test your checkins.