Code

Opened 5 years ago

Closed 4 years ago

#11640 closed (duplicate)

1.1 Test framework fails if CACHE_BACKEND = dummy

Reported by: fgasperino Owned by: dloewenherz
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:

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...

Attachments (0)

Change History (5)

comment:1 Changed 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 5 years ago by Alex

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 4 years ago by dloewenherz

  • Owner changed from nobody to dloewenherz
  • Status changed from new to assigned

comment:4 Changed 4 years ago by russellm

Duplicate of #10853

comment:5 Changed 4 years ago by russellm

  • Resolution set to duplicate
  • Status changed from assigned to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.