Opened 11 years ago
Last modified 10 years ago
#21197 closed Bug
1.6 compatibility checks don't correctly validate TEST_RUNNER — at Initial Version
Reported by: | Russell Keith-Magee | Owned by: | nobody |
---|---|---|---|
Component: | Core (Management commands) | Version: | 1.6-alpha-1 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The 1.6 compatibility checks (executed by the new check management command) don't appear to perform an accurate check.
I can see 5 scenarios that need to be accounted for:
- A default pre-Django 1.6 project
- A pre-Django 1.6 project with TEST_RUNNER set to DiscoverRunner
- A pre-Django 1.6 project with TEST_RUNNER set to something custom
- A default Django 1.6 project
- A Django 1.5 project with TEST_RUNNER set to something custom
The management command does the following:
from django.conf import settings new_default = 'django.test.runner.DiscoverRunner' test_runner_setting = getattr(settings, 'TEST_RUNNER', new_default) if test_runner_setting == new_default: ... output warning ...
That is, it retrieves the current setting value of TEST_RUNNER, and if it is DiscoverRunner, it raises a warning. This behavior:
- Is correct for case 1
- Is possibly incorrect for case 3 and 5, as there's no guarantee the custom test runner subclasses DiscoverRunner (and it probably won't)
- Incorrectly raises an error for case 2 and 4.
There are test cases for the current implementation, but they aren't very solid - they're operating inside a test environment that is itself force setting TEST_RUNNER.