.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.

Solution 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.

Solution 2

Personally, I prefer having a dedicated test-project per real-project. When it comes to building a new feature/module/project, I find it's far better to be able to quickly filter out the suite of other irrelevant test projects. It makes the TDD cycle so much faster to be able to quickly run the tests for my new project as I develop it.

More importantly, it helps you maintain a good organization of your various test/mock classes for your fixtures as needed without cluttering a tonne of unrelated code together. It also makes it much easier for new developers to find the tests that are relevant. Finally, it ensures that the dependencies of your tests for a particular project are never accidentally dependent on another irrelevant project.

Solution 3

My personal choice is to have one testproject per project with just unit tests. The folder structure of this testproject is exactly the same as the project being tested. Besides these make as many integration-test projects as needed.

The main advantage of this approach is that when you want take 1 project and use it in a different solution you always take the testproject together ensuring that when you have to make chances in the new solution the quality remains.

Until now I did not discover any disavantage other than having to replace references more then you have to do when using one testproject.

Comments

[avivr]

look at this question: "Best Practice: Organize Unit Tests" although the solution size in question is different, the guidelines written there are still valid.

[alxbrd]

Test categories are great for CI, and especially for Selenium testing. You can write the user story for a given work item, generate the selenium tests for it, then once the work item is done, at checkin, those tests for the work item are executed together with the whole regression suite. This helps preventing a lot of tiny mistakes from being deployed further down the ci pipe. Now I think I am convinced to create one test project per real project.

[Torbjörn Kalin]

+1 for the shortening the feedback loop: reduce build time by not depending on irrelevant things.