How do people set up their projects for Visual Studio and how do you reference the testable application ?
Right now I've added a separate project creating a .dll to my solution which contains all the test cases and references nunit.framework , and it also references the main .exe file right from the Debug/ folder where VS generates the output.
But I've no idea if that's a good idea - or what the best practices are, anyone want to share their practices ?
That sounds pretty good to me - you can distribute or deploy your application without the test assembly and NUnit, but still test everything. Pretty much standard practice.
I have used a separate folder for all of my tests when using them inside a project. Then you can remove the folder easily when doing an actual build if you choose to.
I have also done what you are saying with a separate project. I think that is fine.
Typically, I have a solution containing a number of projects without any unit tests in that main solution - this is the solution that gets built in Release mode for a true build.
For a specific project, I have a separate solution which contains the project I want to unit test (and any dependent ones) and a MyProjectName.UnitTests project which house all the unit tests for that project. These unit test projects are then configured within a Continuous Integration machine to get build in debug mode and then the tests run.
Works well for me.
Assuming that the test project is in the same solution as the project(s) under test, a small improvement could be to add a reference to the project(s) under test rather than to the binary in the Debug folder.
In addition to what has been mentioned here, I often also use the InternalsVisibleTo assembly attribute to make the internal classes of the assembly I am testing visible to the test assembly i.e. so that they can also be tested directly.
Depending on the isolation framework of your choice, you might also need to make the internals of your assembly under test visible to isolation framework components to be able to mock/stub certain internal behaviours.
I don't think there's anything wrong delivering dlls containing code that proves that even the dll in a production envorinment is still working within established parameters :). In case of weird errors you can still run the unit tests with the release dll and see if something broke in a weird way. Because of this and because I don't like having twice the number of projects in a solution I prefer to add a Tests folder in each project where all the unit test code goes. Simple and effective.
Regards,
Sebastiaan