Testrunner tests fail with unittest2 installed

[Florian Apolloner]

(d8e222551818f5a0)florian@apollo13:~/sources/django.git/tests$ PYTHONPATH=.. ./runtests.py --settings=test_sqlite test_runner
Creating test database for alias 'default'...
Creating test database for alias 'other'...
.....E.......................
======================================================================
ERROR: test_dotted_test_method_vanilla_unittest (test_runner.test_discover_runner.DiscoverRunnerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/florian/sources/django.git/tests/test_runner/test_discover_runner.py", line 37, in test_dotted_test_method_vanilla_unittest
    ["test_discovery_sample.tests_sample.TestVanillaUnittest.test_sample"],
  File "/home/florian/sources/django.git/django/test/runner.py", line 63, in build_suite
    tests = self.test_loader.loadTestsFromName(label)
  File "/home/florian/.virtualenvs/d8e222551818f5a0/local/lib/python2.7/site-packages/unittest2/loader.py", line 133, in loadTestsFromName
    test = obj()
TypeError: unbound method test_sample() must be called with TestVanillaUnittest instance as first argument (got nothing instead)

----------------------------------------------------------------------
Ran 29 tests in 4.162s

FAILED (errors=1)
Destroying test database for alias 'default'...
Destroying test database for alias 'other'...

This only happens when unittest2 is installed from pypi.

[Carl Meyer]

This is due to a bug in the unittest2 PyPI backport: ​http://code.google.com/p/unittest-ext/issues/detail?id=68

As part of the discovery-runner commit, I applied the fix shown there in our bundled unittest2, but since we privilege the PyPI version, if installed, the bug can still bite in that case.

I can't think of a way to fix this in Django (short of always preferring django.utils.unittest over a unittest2 from PyPI, which I don't think we should do), so I think we just need to wait until it's fixed in unittest2 (or we drop Python 2.6 support, at which point it's moot).

I suppose we could apply a "fix" that marks that test as an expected failure under Python 2.6 if unittest2 is installed from PyPI.

[Carl Meyer <carl@…>]

In a7dc13ec231faf917c3125eb4c158138d4edde10:

Fixed #20437 - marked a test-runner test as expected-fail under certain conditions.