Should Unit Tests be in their own project in a .Net Solution

Question

Should I start a new project for my unit tests? That would mean that I would get two executables correct? Then I am worried about the namespace organization. Would I be able to put the unit test in the same namespaces as the classes that they are testing although they are part of a different project?

This raises another question. I know that namespace naming convention is CompanyName.TechnologyName.Feautre.Design. How would I get this right in my solution/project layout? Does the solution name = companyname, project name = technology name?

If that is the case does that mean I can't separate my unit tests into a new project.

Answer 1

The best approach is to have a separate unit test project per 'production project'. This ensures that you can vary and move them around in pairs.

If you have one unit test project covering more than one target project, this creates an artificial tight coupling between these two projects, because you will not be able to compile the unit test project without all of its target projects. This, again, makes it really hard to test a single project in isolation - which is what unit testing is all about.

It's very important to keep unit tests in separate libraries, because this ensures that you test only the public API of your code (black box testing).

I name my namespaces by appending "UnitTest" after the target namespace.

Answer 2

I tend to have a specific test project/assembly per assembly. The test assembly will have the same name as the assembly it is supposed to test, with the addition of the .Test in the name and the namespace.

That way, you keep your tests isolated and they do not get deployed with your production code.