A: 

This might sound silly but I'm going to go for the obvious have you given your test project a reference to the other project?

Other issues that are common for this kind of issue is the use of internal classes which can't accessed from another project/namespace.

Omar Kooheji
+1  A: 

I found a bug report that says Visual Studio incorrectly expands the TargetPath and TargetDir macros. They expand to the obj\ directory, not bin\

[Update] The problem/solution is actually discussed in the Visual Studio Support section of the documentation. Since the 'Target' macros point to obj\, you can't use them out-of-the-box. I ended up using the following expression in the Arguments field:

$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt)
David J
A: 

Also make sure your assembly output path corresponds to what is set up in your NUnit configuration. I have the same setup but I don't have to set 'copy local = true'

TT
A: 

Is the problem with it not finding the application itself, or one of the application's dependencies? You might try using either FileMon or the Fusion Log Viewer to see what exactly is failing. It's possible the issue isn't in finding the app itself, but in locating another dependency. Make sure any dependencies have Copy Local set to True.

How exactly are you starting the NUnit GUI within VisualStudio? If you are setting the "Start external program" under the project's properties, it gives you the option of specifying the working directory. You may need to change this to the build location of your test dll.

Pedro