This is a lesson I’ve learned over and over, but sometimes still need a reminder.

Yesterday, I was working on setting up the unit tests for a Google App Engine-based project I’m working on.  Out of the box, it looks to me like Django runs all of its tests from a tests module that can be created for each INSTALLED_APPLICATION.

I like to keep my unit tests close to the code they’re testing (e.g. if the test is going to be testing myapp.models.foo, I like to have myapp.models.tests.foo_test).  Since this isn’t how Django seems to work, I started looking for ways to have it automatically discover the tests.  Nose came really close, it successfully found all of my tests… but they all failed, since they weren’t running with GAE loaded up.  After a bunch of surfing and experimenting, I came to the conclusion that my easiest route would probably be to roll my own… I mean, how hard can it be?

So I’ve got a few hours into it, and I’m running into snag after snag after snag (mostly due to my unfamiliarity with the intimate guts of the Python unittest module).  I’m getting a bit frustrated, and feel like I’m putting way too much effort into it… Then Shawn comes by and says “well, why not just hard-code the list of places to look for now?  We can fix it when it gets more complicated.”

Here’s what the code ended up looking like:

import x.models.tests
import x.views.tests

TEST_PACKAGES = [
    x.models.tests,
    x.views.tests
]

def suite():
    """Iterate across all of the tests from the submodules, and return a TestSuite
    that will run all of them."""
    test_suite = unittest.TestSuite()
    for test_pkg in TEST_PACKAGES:
        test_suite.addTest( unittest.TestLoader().loadTestsFromModule( test_pkg ))
    return test_suite

Sigh… Oh well, it works great now.

Note: I realize that the source above is getting cut off at the edge of the page.  I’m still figuring out all this WordPress stuff