Should Unit Tests Share A Bed With Production Code?

I'm wrestling with the question of why not place unit tests in the production code assembly? Perhaps even in the same file as the class under test. When I first started doing unit tests this is how I started as it allowed testing protected and even private methods. But now I feel this is a code smell but I'm unable to quantify as to why (which is a smell in itself).

I'll probably end up editing this post as this is really a thinking exercise. I do feel that tests ought to be in a separate assembly and ought to only test public behaviour.

In support of in assembly/file unit tests:

• Easier to find the tests
• Enables testing of internal and protected methods.
• As the tests reside in the production assemblies it means that a deployed application can be unit tested.
  

In the other corner:

• TDD makes us use our code before writing it and as a result makes us think about its design. The public behaviour of a class is all that is important.
• Testing protected or internal members means we are testing aspects not visible to users of the class. Therefore it allows poor encapsulation (my opinion).
• Unit testing is about code development not end user functionality which are covered by user acceptance tests (UATs). So unit tests are useless on a deployed application as they inherently will behave the same (pass). If not, they are not unit tests.

I'm still thinking about this one.