[Django] #21117: FetchFromCacheMiddleware breaks django.contrib.formtools tests

12 views
Skip to first unread message

Django

unread,
Sep 17, 2013, 7:49:05 PM9/17/13
to django-...@googlegroups.com
#21117: FetchFromCacheMiddleware breaks django.contrib.formtools tests
-----------------------------------+-------------------------------
Reporter: dakinsloss@… | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.5
Severity: Normal | Keywords: cache, wizardview
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+-------------------------------
Including FetchFromCacheMiddleware (I have followed instructions to put it
at the bottom of the middleware list) breaks
django.contrib.formtools.tests (because the views get served out of the
cache, not the database). Many of the tests rely on checking
response.context's keys, which are not present for a cached version of the
WizardView. Potential fix includes adding @never_cache (because these
should not be cached anyways) to the WizardView, FormPreview, and
FormWizard. However, this produces a regression for 14576 because the
DummyRequest does not interact well with @never_cache.

--
Ticket URL: <https://code.djangoproject.com/ticket/21117>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Sep 18, 2013, 12:37:36 PM9/18/13
to django-...@googlegroups.com
#21117: FetchFromCacheMiddleware breaks django.contrib.formtools tests
-----------------------------------+--------------------------------------

Reporter: dakinsloss@… | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.5
Severity: Normal | Resolution:

Keywords: cache, wizardview | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------
Changes (by timo):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0


Comment:

If I understand correctly, you are running the formtools tests from your
own application which has custom settings. As part of the test runner
changes in Django 1.6, we're not going to support running Django's tests
with arbitrary settings anymore, so I believe we can close this as "won't
fix". Is my understanding correct?

--
Ticket URL: <https://code.djangoproject.com/ticket/21117#comment:1>

Django

unread,
Sep 18, 2013, 1:30:58 PM9/18/13
to django-...@googlegroups.com
#21117: FetchFromCacheMiddleware breaks django.contrib.formtools tests
-----------------------------------+--------------------------------------

Reporter: dakinsloss@… | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.5
Severity: Normal | Resolution:

Keywords: cache, wizardview | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------

Comment (by anonymous):

Yes--but may I ask why that decision was made and how things like the
survey wizard which depend on sessions (and thus potentially the cache)
will be tested with different cache backends (this is just one instance of
the general question).

--
Ticket URL: <https://code.djangoproject.com/ticket/21117#comment:2>

Django

unread,
Sep 18, 2013, 2:00:30 PM9/18/13
to django-...@googlegroups.com
#21117: FetchFromCacheMiddleware breaks django.contrib.formtools tests
-----------------------------------+--------------------------------------
Reporter: dakinsloss@… | Owner: nobody
Type: Bug | Status: closed
Component: contrib.formtools | Version: 1.5
Severity: Normal | Resolution: wontfix

Keywords: cache, wizardview | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------
Changes (by timo):

* status: new => closed
* resolution: => wontfix


Comment:

Carl Meyer gave
[https://pycon-2012-notes.readthedocs.org/en/latest/testing_and_django.html
a talk at PyCon 2012] which I just skipped briefly and seems to explain
the rationale. One line from those notes: "Some might argue that we need
integration tests to verify that projects integrate properly with things
like django.contrib.auth, but any tests written in django.contrib.auth
that are not isolated are likely to fail, because there are so many ways
to integrate. And an isolated test is probably just purely testing
django.contrib.auth and projects shouldn’t have to care about that."

My interpretation of that is that if you find a bug with a particular
setup, please file a bug and we can add a test for it using
`override_settings` to ensure the test is always run as part of Django's
test suite with a particular combination of settings.

If you have further concerns, feel free to bring it up on the django-
developers mailing this, thanks!

--
Ticket URL: <https://code.djangoproject.com/ticket/21117#comment:3>

Reply all
Reply to author
Forward
0 new messages