Django 1.2 should have optional support for unittest2

[Eric Holscher]

The new additions for unittest2 are awesome, and we should be using them!

I don't know if we want to ship with unittest2 in django, or just do a conditional import in the Test Suite, but I think that 1.2 should support the ability to use the new fancy features in unittest.

[Eric Holscher]

We should also think about trying to move toward the new unit test discovery framework instead of rolling our own.

I talked to Michael Foord, and he says that doing:

try:

import unittest2 as unittest

except ImportError:

import unittest

Should get us some nice new features, like the fancy dict diffing, for free. Then we can use that as a stepping ground for getting more of the useful stuff in core.

[Russell Keith-Magee]

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

[voidspace]

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.

[voidspace]

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

[Paul McMillan]

Attached a patch which bundles unittest2 as discussed in -dev and with the core devs.

[Paul McMillan]

Just an update to note that this patch passes for python 2.4, 2.5, and 2.6 on my systems with sqlite3 and postgres 8.4 and 8.3 (when #13821 is patched).

[Eric Holscher]

Paul:

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.

[Paul McMillan]

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.

[Piotr Czachur]

Please take look on ticket #14049: Fixture loading should be skipped for TestCase decorated with @skip*

[Paul McMillan]

Adds information about unittest changes to contributing and testing docs.

[Paul McMillan]

I think the docs patch resolves ericholscher's concerns. I will address #14049 in a separate patch related to that issue, so as not to complicate this change further.

[Paul McMillan]

patch to bundle unittest2, fix failing tests, and use system version if possible. Updated to work against trunk.

[Paul McMillan]

Updated the patch to apply cleanly against trunk as of #13567.

[Russell Keith-Magee]

First draft of unittest2 support for trunk

[Russell Keith-Magee]

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.

[Russell Keith-Magee]

Second draft of adding unittest2 to trunk

[Russell Keith-Magee]

RC1 of patch to add unittest2 support

[Luke Plant]

I just applied this and ran the test suite with Python 2.4/SQLite (with the patch on #14406 applied), and it ran with no failures (16 tests skipped).

[Russell Keith-Magee]

RC2 of unittest2 patch

[Łukasz Rekucki]

Run this on Python 2.4 with SQLite and PostgreSQL 8.4 (that took a while). All skips look reasonable. Some small things:

• the keyboard_interrupt code isn't needed anymore - unittest2 can do that already. Same thing for the failfast code, so DjangoTestRunner is a noop now.
• I remebered AdminDocsTest needed to be skipped without doctools, so I changed it to use skipUnless like other docutils depended test.

Patch against your patch attached.

[Russell Keith-Magee]

Thanks Łukasz; I've integrated those changes into the patch I'll commit tonight.

[Russell Keith-Magee]

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

[Russell Keith-Magee]

(In [14140]) Refs #12991 -- Added extra docs for the unittest2 changes made in r14139.

[Russell Keith-Magee]

(In [14186]) Refs #12991 -- Added release note about deprecation of DjangoTestRunner.

[voidspace]

The current import logic for unittest/unittest2 is:

If Python 2.7 use standard library unittest
Try locally installed unittest2
Otherwise fallback to bundled unittest2

Can I suggest changing it to:

Try locally installed unittest2
If Python 2.7 use standard library unittest
Otherwise fallback

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.

[voidspace]

I've created a new ticket for my last comment: issue 14486.

[Jacob]

Milestone 1.3 deleted