Any reasons NOT to write self testing Python code?

Question

Whilst writing tests I was giving considerable thought to the question of how to ensure I have tests for every class in my application.

It occurred to me that maybe I should just put the test code into the classes, thereby making it obvious that each class has a test and vice versa.

I found that this is called "self testing code" http://en.wikipedia.org/wiki/Self-testing_code

So of course in software development there's always going to be plenty of people who say THAT'S A TERRIBLE WAY TO PROGRAM, YOU CAN'T DO THAT! I'm interested in hearing what the naysayers have to say about writing self testing classes in Python. What are the reasons its a bad idea?

thanks!

class MyOperation():

    def some_useful_function(self):
         # do some useful function

    def some_other_function(self):
         # do some other function

    class Test_MyOperation():

        def test_something(self):
            # some test code
            assert(True)

        def test_something_else(self):
            # some more test code
            assert(True)

Answer 1

Here are four reasons not to do it:

1. Anyone who reads your code will need to wade through lots of test code. This will make it harder to figure out what it is doing.
2. All of the test code gets loaded into memory even when you are not testing. This is wasteful. (Perhaps not important in these days when 8 GB RAM is normal.)
3. Test code should have exactly the access that other users of the code has. If it is part of the class itself, you make miss things as your test code isn't running in the same context as actual code using the class. (A bigger problem in languages like C++ that enforce privacy but still it can cause issues.)
4. It will make code coverage tools inaccurate

The alternative I've used is to put all test code for foo.py in a file named test/test_foo.py. This makes it trivial to automatically run a test for a given file, and to see what test code applies to what file, without having any of these issues. It also becomes very natural to have an editor with a split window view, one in the real code, one in the test code.