Where to place unit test project

I'm thinking about where to put the unit/integration test project. I follow the 1 test project pr. project convention

I can think of 3 ways, that all seems good to me, which make it kind of hard to choose :-)

1. Test project is put under a Tests sub folder to the project it tests.
2. Test project is put next to the project it tests, in a "project".Tests folder. I believe this is what Roy Osherove recommends.
3. Put all test projects in a sub folder in the root. e.g. \Tests\"pro开发者_如何转开发ject".Tests
4. Something else?

What you choose and why?

Option 2 is my preferred one. Aside from anything else, it's just the default when you create a new class library project - it's under the same solution directory as the production project(s).

To counter the argument about checking out a project without its tests, I find it relatively rare to check out just a project rather than a whole solution. If you're a more "project-based" than "solution-based" shop, that could change things.

I like to have all projects in the same level physically. I have no big argument, just for simplicity. After all visual studio shows all projects in the same level.

.../Project/Project.Web/
.../Project/Project.Model/
.../Project/Project.DataAccess/
.../Project/Project.UnitTest/
etc

Test project is put next to the project it tests, in a "project".Tests folder. I believe this is what Roy Osherove recommends.

This is my personal favorite. Its the one that conveys most clearly the intent, and also makes it easy to see at a glance what test projects go with which projects if you're looking at them inside a directory, or have some reason for grouping projects into a single solution.

I'd go with #1 so that when you do a checkout of the project, you have the tests as well. Otherwise, tests become even MORE of an afterthought.

The default in a Visual Studio 2010 Asp.Net MVC solution is a different project within the same solution. This is a big help when it comes to testing compilation with all your references.

I believe option 2 is the best choice. Tests are a great way to document code. They make clear the semantics of methods and classes. It should be easy for a programmer to jump to the test code for some method he finds dubious.

On the other way, keeping the test code in the same project may make the compiled binary output bigger and force the project to have dependencies needed only by the test code.