Opened 11 years ago
Closed 11 years ago
#21117 closed Bug (wontfix)
FetchFromCacheMiddleware breaks django.contrib.formtools tests
| Reported by: | 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 by , 11 years ago
comment:2 by , 11 years ago
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 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → 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!
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?