Opened 14 years ago
Closed 14 years ago
#14105 closed (duplicate)
django.contrib.auth tests failing with cache middleware
Reported by: | Peter Baumgartner | Owned by: | Paul McMillan |
---|---|---|---|
Component: | Core (Cache system) | Version: | 1.2 |
Severity: | Keywords: | ||
Cc: | christandiono@… | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Steps to reproduce:
- Start a new project. Add
django.contrib.admin
and setup a sqlite database. Test result: OK.
- Add the required cache settings and the update/fetch middleware. Tests result: FAILED (failures=1, errors=27)
I'm testing against a locmem cache with Django 1.2.1 and Python 2.6. I've attached my settings file for reference
Attachments (1)
Change History (10)
by , 14 years ago
Attachment: | diffsettings.py added |
---|
comment:1 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 14 years ago
This seems related to the fact that some of the auth tests add django.contrib.auth.midddleware.RemoteUserMiddleware
to the end of settings.MIDDLEWARE_CLASSES
, breaking the requirement that FetchFromCacheMiddleware
be last. Working on a patch now.
comment:3 by , 14 years ago
Further investigation suggests that it's not a problem with the order of the middleware classes.
The final failure on the test run seems to be caused by django.contrib.auth.views.password_reset_confirm()
not being properly decorated with @never_cache.
I'm still investigating the response.context
issue, but I believe that the cache is bypassing part of the test runner.
follow-up: 6 comment:4 by , 14 years ago
This bug comes down to the following line in client.py:224:
signals.template_rendered.connect(on_template_render, dispatch_uid="template-render")
The problem occurs when a view is rendered any subsequent time in the test run- we will never render any templates, causing our signal that attempts to trap template and context items to never fire, which in turn leads to context and template attributes on HttpResponse being left empty/undefined even though the response content itself and the status_code end up being correct.
I'm not sure of the solution here; they all seem ugly:
- Always set CACHE_BACKEND to 'dummy://' when running tests- sucks if you actually want to test caching concerns like making sure different views go to different users even with caching enabled.
- Set CACHE_BACKEND to 'dummy://' in supplied tests when we know we want to examine context or templates in the response.
- Remove cache middleware explicitly from settings.MIDDLEWARE_CLASSES in these tests.
- Call cache.clear() in test setup/teardown- seems like overkill and is potentially non-safe it people aren't careful about their setup.
- Attempt to set template and context before the response ends up being cached, so when we later retrieve it we get the same results as the first non-cached run.
comment:5 by , 14 years ago
I opened #14446 with a patch to fix the single failure, since it seems to be a separate issue from the major reason this ticket is open.
comment:6 by , 14 years ago
Replying to toofishes:
- Always set CACHE_BACKEND to 'dummy://' when running tests- sucks if you actually want to test caching concerns like making sure different views go to different users even with caching enabled.
- Set CACHE_BACKEND to 'dummy://' in supplied tests when we know we want to examine context or templates in the response.
By the way, these don't seem to work, bizarrely enough. Our cache backend has long been set to dummy because we've been too lazy to set it up, although the two middlewares were still there (and causing tests to fail).
comment:7 by , 14 years ago
Cc: | added |
---|
comment:8 by , 14 years ago
Component: | Contrib apps → Cache system |
---|
This is primarily a cache-related issue.
comment:9 by , 14 years ago
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
Closing as a duplicate of #15142; This ticket came first, but the other ticket has a more complete analysis and a proposed patch.
I can duplicate this problem on trunk.
The test failures all seem to point to
response.context
being returned asNone
.The failures are generally of this form: