How do you structure your unit tests?

In short: Testing of private methods limits the refactoring ability. Thanks to InternalsVisibleTo we can easily test internal members Having that in mind, I really don't see the reason why to keep code and test in the same project

When we were using Web Site Project with ASP.NET (not Web Application Project) we had to put the unit tests in the same place because we didn't have proper DLLs and it was difficult to manage dependencies without copying DLLs, etc.. When we migrate to Web.App. Project we plan to change this.

Thanks to Nikola Malovic. Before now I've kept my NUnit .NET tests in the same assembly, but I'll investigate the InternalsVisibleTo attribute. I don't want to ship my unit tests!

Solution structure:- *Web Application\ - Model - Model Unit Tests - MVC Application - MVC Application Unit Tests *>Some Project - eg. SilverLightEncoder Server< *>Another project< *Solution Items

For every type in my project, I have a corresponding type that end in 'Spec', for example, SomeObject has a unit test called SomeObjectSpec. I've found this gets around some of the resistance from managers (and sometime other developers) who's opinion is that we don't need "Unit Tests". They have more of a difficult time saying No to the questions of "Do we need specifications?" ! Cheers, Steve