Organizing NUnit Test in a .Net or MonoDevelop Solution

When I first use Nunit, I was confused on how to set up Nunit test inside a solution. I can think of several alternatives:

1. Have Nunit test be in the same project / Assembly.
2. Same as 1, but use a compiler flag like #ifdebug to filter out the Nunit code during production.
3. Create a single test project where unit test for all solutions resides. So there is a single “Unit Test” project solution where all of the unit test are stored.
4. For each project in the solution being tested, create a corresponding test project. So if you have a “Calculation” project, you would have a corresponding “Calculation Test” project that holds all of the unit test for Calculation Project.

Personally, I do not like option 1 because it deploys Nunit code into production. I do not like option 2 because preprocessor macros are error prone. In addition, if you are only testing when the debug flag is true, are you really testing the code?

I prefer option 4 over option 3 because it gives me the flexibility to organize the test and also promote isolation between different tests. If you lump all of the test under the same project, it may be difficult to figure out which test is from which project.

For example, if we want to do a Calculator application, you’ll end up with the following solution structure:

Calculator — Solution for the calculator application

CalculatorApplication — Startup project. Contains the main routine.

CalculatorClass — this is the class code for the calculator.

CalculatorClassTest — this is the unit test for the CalculatorClass.

For each project will have a corresponding unit test project. The unit test project will reference the assembly of the project being tested. The CalculatorApplication just enough code to call the other classes. It is not tested. It may be a pain to setup at first, but it is the most organized and flexible way to organized your unit test.