Chris Adams

At work we're using Hudson for continuous integration on our Django projects. Every time someone checks a commit in to SVN, hudson runs our entire test suite in a virtualenv and reports failures as well as generating various test reports.

Overall it's been a win but there are some rough edges:

1. The Django test runner's environment is enough different from the normal one that it can break various things we use: the dynamic model extension FeinCMS performs can break if the test runner initializes apps in a different order (some quality test debugging time), South database migrations, and some of the built-in caching middleware (see #5176).
2. We don't want to test every application installed - just our site and the other code which we developed. One convenience you'll want to customize in the code below is the logic which includes apps with a common prefix along with the site's app if you didn't specify the apps on the command-line. We also include a couple of opensource apps which are maintained by people on our team since there's a very clear path for error reporting failures: shouting across the room.
3. We want to use Ned Batchelder's awesome coverage.py. Unfortunately, we can't load it in the stock test runner because things like our models have already been processed by the time a management command runs and we'd like those to be included in our test reports.

The solution was to write a custom test runner which works like the standard Django command but customizes the environment: http://gist.github.com/288810