#21197: 1.6 compatibility checks don't correctly validate TEST_RUNNER
-------------------------------------+-------------------------------------
Reporter: russellm | Owner: nobody
Type: Bug | Status: new
Component: Core (Management | Version:
commands) | 1.6-alpha-1
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old 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:
>
> 1. A default pre-Django 1.6 project
> 2. A pre-Django 1.6 project with TEST_RUNNER set to DiscoverRunner
> 3. A pre-Django 1.6 project with TEST_RUNNER set to something custom
> 4. A default Django 1.6 project
> 5. 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.
New 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:
1. A default pre-Django 1.6 project
2. A pre-Django 1.6 project with TEST_RUNNER set to DiscoverRunner
3. A pre-Django 1.6 project with TEST_RUNNER set to something custom
4. A default Django 1.6 project
5. A Django 1.6 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.
--
Comment (by shai):
Note similar discussion on mailing list:
[https://groups.google.com/forum/#!topic/django-developers/reoiSYbPviQ
Django 1.6 and migrating to the new test runner: note on user experience].
The discussion is not about the "check" command, but essentially asking to
incorporate some "check" functionality into the "test" command.
Note in particular that my suggestion to add a settings knob specifying
the Django version the project is expecting (which would default to 1.5,
with 1.6 in the default project templates) should also allow easy
resolution of this bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/21197#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.6b2180874ecebd593ac52562f2d3e36b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
