Opened 7 years ago

Closed 6 years ago

#11640 closed (duplicate)

1.1 Test framework fails if CACHE_BACKEND = dummy

Reported by: fgasperino Owned by: Dan Loewenherz
Component: Testing framework Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


1.1 seems to fail built-in contrib/sessions/ if the cache api is enabled, but set to dummy.

CACHE_BACKEND = 'dummy:///'
#CACHE_BACKEND = "locmem:///?timeout=300&max_entries=1000"


#CACHE_BACKEND = 'dummy:///'
CACHE_BACKEND = "locmem:///?timeout=300&max_entries=1000"


FAIL: Doctest: django.contrib.sessions.tests

Traceback (most recent call last):

File "/home/franco/lib/python2.6/site-packages/django/test/", line 2180, in runTest

raise self.failureException(self.format_failure(new.getvalue()))

AssertionError: Failed doctest test for django.contrib.sessions.tests

File "/home/franco/lib/python2.6/site-packages/django/contrib/sessions/", line 0, in tests

File "/home/franco/lib/python2.6/site-packages/django/contrib/sessions/", line 166, in django.contrib.sessions.tests
Failed example:






File "/home/franco/lib/python2.6/site-packages/django/contrib/sessions/", line 188, in django.contrib.sessions.tests
Failed example:







Ran 36 tests in 1.284s

Destroying test database...

Change History (5)

comment:1 Changed 7 years ago by Russell Keith-Magee

Confirmed that these tests fail - however, it's not entirely surprising.

The cache session backend uses the cache to store the session data. The dummy cache backend is pretty much, by definition, a cache that remembers nothing. The test is validating that session data has been stored - and the dummy cache doesn't do that. Ergo, failure.

I presume you are reporting this because you have a project that is (legitimately) using sessions with the db (or other non-cache) session backend, and is using the dummy cache, either for testing or because you haven't hit the need for caching yet. This configuration will introduce a failure into the project test suite even though there isn't actually anything wrong.

This is an example of a bigger problem that we need to address with Django's testing - the difference between application release testing and project integration testing. This is something I'm hoping to address in the v1.2 timeframe.

comment:2 Changed 7 years ago by Alex Gaynor

Triage Stage: UnreviewedAccepted

comment:3 Changed 7 years ago by Dan Loewenherz

Owner: changed from nobody to Dan Loewenherz
Status: newassigned

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

Duplicate of #10853

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

Resolution: duplicate
Status: assignedclosed
Note: See TracTickets for help on using tickets.
Back to Top