Opened 9 years ago

Closed 9 years ago

#25674 closed Bug (invalid)

regression in test discovery

Reported by: Brian May Owned by: nobody
Component: Testing framework Version: 1.8
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I looked through https://docs.djangoproject.com/en/1.8/releases/1.8/ and didn't find anything - apologies if I missed something.

Looking at django-guardian project from https://github.com/django-guardian/django-guardian/tree/v1.3 - the latest release

If I run the tests using Django 1.7, all the tests run.

If I run the tests using Django 1.8 and Python 2.7 or Python 3.4, it can't find any of the tests.

If I run the tests using Django 1.8 and Python 3.5 it can find the tests.

The tests, fail badly for Django 1.8 however that is not the point of this ticket; rather the point is that the tests are not discovered with Django 1.8 unless Python 3.5 is used. This would appear to be a regression.

Or if this is not a regression, please tell me what I missed.

The tests are in guardian/testapp/tests/init.py which selectively imports from *_test.py files.

I also filled a bug report at django-guardian, see https://github.com/django-guardian/django-guardian/issues/356

Change History (6)

comment:1 by Tim Graham, 9 years ago

Could you please use git bisect to find the Django commit that introduced the behavior change?

comment:2 by Brian May, 9 years ago

Ok, will look into doing a bisect. Just as soon as I get some time :-)

comment:3 by Brian May, 9 years ago

Having problems doing a reliable bisect.

bbe7964185fb786599b9f4bcaa07fc54156c9e0d - migrations don't seem to work properly, get "django.db.utils.OperationalError: no such table: auth_email" - this appears to happen before test discover although I am not 100% certain on this.

next commit:

e55d888b6680a45ca957434599c37f0286034cab - no errors, no tests being run.

So it is possible that I found the commit that causes the problem. Or I found the commit that fixes the db migration issue - which I don't particularly care about. In actual fact I don't see anything in that commit at quick glance should do any of the above.

Is there some work around for the no such table error so I can get a more reliable bisect?

comment:4 by Brian May, 9 years ago

Still trying to understand this, however beginning to think this isn't a Django regression after all. The file guardian/testsettings.py contains:

if django.VERSION < (1, 8):
    TEST_RUNNER = 'django.test.simple.DjangoTestSuiteRunner'
else:
    TEST_RUNNER = 'django.test.runner.DiscoverRunner'

So it might be expected behavior for the different test runner.

Still don't understand why Python 3.5 is different, suspect there might be a good explanation for this too.

comment:5 by Brian May, 9 years ago

From a Debian mailing list discussion:

"There was a change in unittest autoloader in Python 3.5. It now tries to import the package even if it has no tests. ... http://bugs.python.org/issue22457"

So I suspect Python 3.5 loads guardian/testapp/tests/init.py even though it didn't find any tests, and suddenly discovers the tests.

Think we can close this bug report.

comment:6 by Tim Graham, 9 years ago

Resolution: invalid
Status: newclosed

Looks correct to me, thanks for the analysis.

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