This is worth pursing, but would be a significant feature addition (or at least feature change), so it will need to wait for a later release.

Exactly how we can use it will require some discussion - while it would be great to switch to using unittest2's test discovery, our usual policy of not requiring dependencies will mean we need to continue to ship a native unittest version (or ship a copy of unittest2).

If there is anything I can do to support Django in using unittest2 let me know. Not just test discovery - the new addCleanups, new asserts, conditional skips and expected failures could be very useful for Django.

If you just have optional support for unittest2 (as this ticket suggests) then you still get the better failure messages for assertEqual when unittest2 is available.

unittest2 now has an implementation of failfast and control-c handling, which may duplicate some of your test runner functionality. If you *ship* unittest2 it may mean you can delete some code from your test runner. There are also class / module level fixtures (setUpClass etc).

We probably need to add documentation for these changes. I'm thinking in the Testing Django document, and maybe a note in the contributing section as well. Otherwise this looks good to me.

A summary of the patch:

The changes in tests/regressiontests/test_client_regress/models.py are to address changes in the string output of exceptions in unittest2. Otherwise this is just the importing of stock unittest2 with 2 changes:

The imports inside of unittest2 where absolute (from unittest2...) -- we had to change these to import from the django source tree so they are valid. This is the same approach taken in the simplejson module already included in Django.

The init.py was moved to another file and the new init is doing some magic to check if the user already has 2.7 or another version of unittest2 installed, and uses that before the bundled one. This is because it is assumed that people might have more up to date versions of the package than we ship.

The import for the new package is django.utils.unittest -- we made this unittest instead of unittest2 because unittest2 is actually just the unittest package from 2.7. So you can import django.utils.unittest in your package and know you are getting the 2.7 version of unittest.

One possible backwards compatibility issue this brings up is in user tests. Because unittest2 changes error reporting to be more verbose, users who are doing the wrong thing and have written tests which compare against exact, specific error strings (as was done in test_client_regress/models.py), there is a possibility that some user unittests may not work after this patch. This problem is introduced at the python level, and it seems that the general Django policy is not to support users who are doing the wrong thing.

Second draft patch now available for testing. See ​the mailing list thread for details on the changes. Any assistance testing this patch on multiple python versions, database versions, and especially on Oracle and GeoDjango would be gratefully accepted.

(In [14139]) Fixed #12991 -- Added unittest2 support. Thanks to PaulM for the draft patch, and to Luke, Karen, Justin, Alex, Łukasz Rekucki, and Chuck Harmston for their help testing and reviewing the final patch.

This allows Python 2.7 users to still upgrade to a more recent version of unittest2 and use that locally. (New features added to unittest in Python 3.2 are still being added to unittest2.) Without this Python 2.6 (and earlier) users will be able to use a locally installed unittest2 but Python 2.7 users *won't*, which seems inconsistent.