Recently I came into some very old post about handling unit test code name space and locations. It really looked a lot of effort for very simple tasks.
I don't put my unit test code into a separate project/assembly. The reason is simple, the unit test codes is not secondary citizen and shall be treated as seriously as "production" codes, if not more seriously. You may argue that shipping unit test codes to end user is meaningless. While, I kind of agree. So if you do want stripping the unit tests off your production assembly, a little trick will help, wrap all your unit test codes with a macro check:
#if DEBUG
using NUnit.Framework;
namespace your.name.space
{
}
#endif
and the final release build will not contain any unit test codes. Still your assembly will depend on NUnit assembly and by default the NUnit DLL will appear in your release folder. Removing it won't do any harm.
I came from Java camp and had the habit to put source code and test code side by side, that is, source code is under "project_root\src\" and test code under "project_root\Test\" folder. I know it's not a common practice in .NET world to have a "src" folder, but it does no harm and give me the feasibility to put more resource under the project root folder, besides the benefit of separate the unit test codes into different folders, so I'm going to stick with it. If you happen to have some convention to make folder structure appear in namespace structure, then another trick to overcome it is, in project browser, select the "src" folder and press F4 to bring up the property windows, then set the "contribute to namespace" option to false.
