Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#15828 closed Bug (fixed)

multiple inheritance in TestCases does not work with unittest2

Reported by: Ricardo Kirkner Owned by: nobody
Component: Testing framework Version: 1.3
Severity: Release blocker Keywords: unittest2
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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:

Attachments (2)

unittest-django-vs-unittest-0.5.1.diff (9.3 KB) - added by Aymeric Augustin 7 years ago.
unittest-django-vs-python-2.7.2.diff (55.4 KB) - added by Aymeric Augustin 7 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by Carl Meyer

Easy pickings: unset
Triage Stage: UnreviewedAccepted

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.

comment:3 Changed 8 years ago by Ramiro Morales

UI/UX: unset

From what I can see, this has been solved in the unittest2 Hg repository ( 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.

comment:4 Changed 8 years ago by 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.

comment:5 Changed 8 years ago by Russell Keith-Magee

Severity: NormalRelease blocker

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.

comment:6 Changed 7 years ago by Aymeric Augustin

We're reaching the date for 1.4 alpha, and unittest2 0.6 hasn't been released yet:

comment:7 Changed 7 years ago by 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:

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.

Changed 7 years ago by Aymeric Augustin

Changed 7 years ago by Aymeric Augustin

comment:8 Changed 7 years ago by 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

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

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by Aymeric Augustin

After scratching my head a lot on this problem, I'm just going to backport

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.

Last edited 7 years ago by Aymeric Augustin (previous) (diff)

comment:11 Changed 7 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

In [17398]:

Fixed #15828 -- Removed explicit implementation of empty setUp / tearDown methods. Backport of

comment:12 Changed 7 years ago by 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.

comment:13 Changed 7 years ago by Aymeric Augustin

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

Note: See TracTickets for help on using tickets.
Back to Top