Opened 7 years ago

Closed 6 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: UI/UX:

Description

Steps to reproduce:

  1. Start a new project. Add django.contrib.admin and setup a sqlite database. Test result: OK.
  1. 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)

diffsettings.py (1.1 KB) - added by Peter Baumgartner 7 years ago.

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by Peter Baumgartner

Attachment: diffsettings.py added

comment:1 Changed 7 years ago by Paul McMillan

Owner: changed from nobody to Paul McMillan
Status: newassigned
Triage Stage: UnreviewedAccepted

I can duplicate this problem on trunk.

The test failures all seem to point to response.context being returned as None.

The failures are generally of this form:

======================================================================
ERROR: test_last_login (django.contrib.auth.tests.remote_user.RemoteUserCustomTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/django/contrib/auth/tests/remote_user.py", line 87, in test_last_login
    self.assertNotEqual(default_login, response.context['user'].last_login)
TypeError: 'NoneType' object is unsubscriptable

comment:2 Changed 7 years ago by Paul McMillan

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 Changed 7 years ago by Paul McMillan

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.

comment:4 Changed 7 years ago by Dan McGee

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 Changed 7 years ago by Paul McMillan

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 in reply to:  4 Changed 7 years ago by Chris Tandiono

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 Changed 7 years ago by Chris Tandiono

Cc: christandiono@… added

comment:8 Changed 6 years ago by Julien Phalip

Component: Contrib appsCache system

This is primarily a cache-related issue.

comment:9 Changed 6 years ago by Russell Keith-Magee

Resolution: duplicate
Status: assignedclosed

Closing as a duplicate of #15142; This ticket came first, but the other ticket has a more complete analysis and a proposed patch.

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