multiple inheritance in TestCases does not work with unittest2

[Ricardo Kirkner]

Using multiple base testcases used to work in django 1.1 but stopped working in django 1.3, due to the introduction of unittest2.

In django.utils.unittest you can see that TestClass.setUp doesn't call super. This breaks the mro chain call, preventing further bases classes from getting initialized.

A bug has been filed about this on unittest2: ​https://code.google.com/p/unittest-ext/issues/detail?id=61

[voidspace]

Note that the easiest fix is just to delete the setUp and tearDown methods provided by unittest2.TestCase. This is the fix that will be applied in unittest2 0.6.0.

[Carl Meyer]

We should follow the lead of unittest2 here - we don't want to diverge. It may be that this is most easily done by applying all the changes in 0.6.0 at once rather than piecemeal, but in either case we should do this in the end.

[Ramiro Morales]

From what I can see, this has been solved in the unittest2 Hg repository (​http://hg.python.org/unittest2/rev/3d33f92496fa). But a similar problem seems to be still present in unittest shipped with Python ​2.7, ​3.2 and ​trunk

So, from the Django POV, solving this in our copy of unittest2 (be it either by porting that isolated change or waiting for the 0.6.0 release) would solve this issue for people using Python < 2.7 but a different, buggy behavior for people using 2.7.x.

[voidspace]

Because unittest2.TestCase inherits from unittest.TestCase (and did not call up to its base class) it has the problem with multiple inheritance. unittest.TestCase doesn't inherit from another TestCase and so shouldn't have the same bug - and doesn't need fixing.

I'm hoping to get a 0.6 release out soon, but this particular fix is very easy to apply on its own.

[Russell Keith-Magee]

I'm going to mark this as a release blocker; if there's a 0.6 release of unittest2 in the wings that will address this problem, we should make sure we apply that update before we release 1.4. If the 1.4 cycle finishes before unittest2 0.6.0 is ready, we can look at our other options.

[Aymeric Augustin]

We're reaching the date for 1.4 alpha, and unittest2 0.6 hasn't been released yet: ​http://pypi.python.org/pypi/unittest2

[Aymeric Augustin]

I investigated a little bit more. Currently, we're shipping unittest2 0.5.1, with very few changes:

• code to load unittest2 (when it's available) or unittest from the stdlib (on Python >= 2.7)
• stylistic changes that must be side-effects of project-wide cleanups

A more recent "official" version is the code shipped in Python 2.7.2 (tag: ​http://hg.python.org/cpython/rev/eb3c9b74884c).

I'm attaching the diff between the version currently shipped by Django and a) unittest 0.5.1 b) Python 2.7.2 for future reference.

[Aymeric Augustin]

Since the last commit on unittest2 was 8 months ago, I'm not sure it's a good idea to wait for 0.6.0. See ​http://hg.python.org/unittest2

How about switching to a copy of the stdlib's version instead?

[Russell Keith-Magee]

It might be worth poking voidspace to see if he has any plans to do a formal 0.6 release; if not, I don't see any problem with taking code from the CPython 2.7.2 branch.

[Aymeric Augustin]

After scratching my head a lot on this problem, I'm just going to backport ​http://hg.python.org/unittest2/rev/3d33f92496fa.

Since we don't copy unittest2's own tests, I will only backport the fix, not the related test.

The bug will still be present for users of Python 2.7.2 until it's fixed in Python, but there isn't anything we can do about this. They have the option to install an hg checkout unittest2 to get a patched version.

This appears to be the least stupid thing to do.

[Aymeric Augustin]

In [17398]:

Fixed #15828 -- Removed explicit implementation of empty setUp / tearDown methods. Backport of ​http://hg.python.org/unittest2/rev/3d33f92496fa.

[voidspace]

I don't know why users of Python 2.7.2 will see a bug? The problem only exists for unittest2 which overrode the base unittest.TestCase.setUp surely? (So for users of Python 2.7 using unittest.TestCase directly instead of unittest2.TestCase the problem doesn't exist - unless I'm misunderstanding something.)

Note that just bundling the Python 2.7 version of unittest is not a good alternative to bundling unittest2. unittest2 includes fixes for compatibility with earlier versions of Python - plus it explicitly inherits from the appropriate unittest classes. If you just bundled the 2.7 stdlib unittest then your TestCase would not be a subclass of the "real" unittest.TestCase, which would likely cause problems for many test runners.

[Aymeric Augustin]

voidspace: thanks for your comments, I hadn't fully understood the implications.