From what I've seen and done, the standard practice for writing NUnit
tests for a project is to create a separate project to contain the
tests. So for example if I have a project "MegaApp.DomainModel", I
would create a corresponding project "MegaApp.DomainModel.Tests" that
would have all the tests for that project. Recently I've been thinking
about putting the tests directly into the "MegaApp.DomainModel"
project in such a way that "Widget.cs" and "WidgetUnitTests.cs" would
be right next to each other in the Solution Explorer.

There are a couple advantages to this approach:

* The nearness of the files will make it easier (and therefore more
likely) that developers will work on the test in tandem with the class
under test (CUT).
* One can make private methods on the CUT into internal methods and
then write tests for them, if need be.
* Will effectively halve the number of projects in the solution (My
current solution has 40+ non test projects), making the solution
explorer a little less unwieldy.
* I'm thinking this will make it easier for devs unfamiliar with NUnit
testing to gain experience with it faster. (I'm currently trying to
introduce the concept to 10+ developers.)

And the only disadvantage I have thought of so far:

* The production assemblies have a reference to NUnit and contain more
types. Slower compilation and load time?

Thinking about it, that disadvantage really isn't that big of a deal
to me. So far I haven't thought of any other disadvantages. I'm
looking for any more advantages/disadvantages for this approach vs the
norm. Thoughts?