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?


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

        def test_something_else(self):
            # some more test code
  • 5
    Ensuring that everything has a test is far more effectively done via code coverage (run the tests, check what code got executed).
    – user7043
    Jan 26, 2015 at 22:13
  • 3
    You've doubled the code length and all that you added is cruft that is orthogonal to the main code. That's a huge distraction for the reader. And coverage testing.
    – msw
    Jan 26, 2015 at 22:26

1 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.

  • 5
    One more for the list: in order to build/run the production code, you need to install the tests' dependencies Jan 27, 2015 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.