Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#15828 closed Bug (fixed)

multiple inheritance in TestCases does not work with unittest2

Reported by: ricardokirkner 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

Description

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

Attachments (2)

unittest-django-vs-unittest-0.5.1.diff (9.3 KB) - added by aaugustin 3 years ago.
unittest-django-vs-python-2.7.2.diff (55.4 KB) - added by aaugustin 3 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 4 years ago by voidspace

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 4 years ago by carljm

  • Easy pickings unset
  • Triage Stage changed from Unreviewed to Accepted

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 4 years ago by ramiro

  • UI/UX unset

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.

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

  • Severity changed from Normal to Release 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 3 years ago by aaugustin

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

comment:7 Changed 3 years ago by aaugustin

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.

Changed 3 years ago by aaugustin

Changed 3 years ago by aaugustin

comment:8 Changed 3 years ago by aaugustin

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?

comment:9 Changed 3 years ago by russellm

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 3 years ago by aaugustin

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

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.

Version 0, edited 3 years ago by aaugustin (next)

comment:11 Changed 3 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed

In [17398]:

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

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

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

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