Opened 15 years ago

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

Description

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

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

vs

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

Tests:

======================================================================
FAIL: Doctest: django.contrib.sessions.tests


Traceback (most recent call last):

File "/home/franco/lib/python2.6/site-packages/django/test/_doctest.py", 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/tests.py", line 0, in tests


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

cache_session.exists(cache_session.session_key)

Expected:

True

Got:

False


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

cache_session.exists(key)

Expected:

True

Got:

False

vs


Ran 36 tests in 1.284s

OK
Destroying test database...

Change History (5)

comment:1 by Russell Keith-Magee, 15 years ago

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 by Alex Gaynor, 15 years ago

Triage Stage: UnreviewedAccepted

comment:3 by Dan Loewenherz, 14 years ago

Owner: changed from nobody to Dan Loewenherz
Status: newassigned

comment:4 by Russell Keith-Magee, 14 years ago

Duplicate of #10853

comment:5 by Russell Keith-Magee, 14 years ago

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