#21117 closed Bug (wontfix)

FetchFromCacheMiddleware breaks django.contrib.formtools tests

Reported by: dakinsloss@… Owned by: nobody
Component: contrib.formtools Version: 1.5
Severity: Normal Keywords: cache, wizardview
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (3)

comment:1 Changed 18 months ago by timo

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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?

comment:2 Changed 18 months ago 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).

comment:3 Changed 18 months ago by timo

  • Resolution set to wontfix
  • Status changed from new to closed

Carl Meyer gave 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!

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