In .NET should you place unit test projects in with the rest of the solution? Or should there be a test solution that houses all the test projects?
We have all the test projects in with our code base solution...it seems a bit cumbersome.
What do you usually do?
I've always kept them as part of the solution - they are, after all, part of the solution. You can have multiple solutions though for different approaches to viewing your projects, so a testless solution may be what you'd want to create for some cases.
In our current project we decided to put all unit tests in separate projects. The application code and tests are in the same solution, but at least we can build (and deploy) a version without the unit test code.
The downside of this -so far- has been that sometimes your unit tests can't reach certain members of the application code (protected and internals), but that usually lead us to discover that our design could be improved.
And I guess I should point out a similar thread Here with more answers on the same/similar topic.
I don't use .NET, but when I develop test cases of any sort, I keep them isolated from the rest of the code so that I can deploy the application without the tests. The user doesn't need, or even want that stuff.
Our test code doesn't ship but they are part of the solution as a whole. Our builder separates out test assemblies and core components. From a solution management perspective it seems like a solution with 140+ projects is overwhelming.
We always use a separate project within the same solution.
This means that we can be certain (using references) that the unit-test code also tests our explicit references (rather than implicitly picking up some visibility of something because it is in the same assembly -- e.g. "Internal")
Look at the design of your project. If it is anywhere close to the MVC layout or one of it's alternatives then you should have distinct levels of different assemblies. Make one test subassembly for each level of your design.
Our test project usually runs in place of the project that creates the EXE. Our EXE project is a thin shell that passes event and information to an assembly filled with controller classes that has the code most people put into a EXE Project. This allow the Test Project to pretend to be the EXE for 90% of the normal testing process.
We are still working out the best arrangement for the actual test cases. Right now we have several major levels of our framework Utility, Applicaiton Objects, UI Framework, Commands, UI Controllers, and EXE. We have one assembly for each level except for EXE (which is tested manually). When we edit an assembly we load the test assembly for that level. When we need to do something that touches every level we have to load all the test assemblies.
During our one button build process we run the test project exe. (We have a separate utility for this).
Generally I put unit tests in their own project and integration tests in their own project within the application solution.
Where I work we are considering putting web tests in a separate solution. We plan to share web test authoring with the QA team and we don't want these tests to become a build liability.