Question

I am working on a Django project, using the Satchmo shopping cart software. I have to use fairly complex custom code for this project, thus would like to have all Django and Satchmo tests passing.

However, one of the tests only works in isolation, to be precise the custom.ShopTest.test_custom_product in product/modules/custom/tests.py. This test works in isolation (i.e. with ./manage.py test custom.ShopTest) but not when I run all tests together (./manage.py test).

This test opens the home page using the Django test client and asserts if some texts are contained on the page. When I load the same fixture in the production database, these texts are on the page as well.

Also, when the test starts, the product whose title should be shown on the page does also exist in the test database, so the fixture is loaded correctly.

I think some of the other Satchmo apps breaks testing in some way, but I always assumed that Django runs the tests as much as possible in isolation.

EDIT:

The output of the failing test is:

======================================================================
FAIL: test_custom_product (product.modules.custom.tests.ShopTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/Projects/satchmo/satchmo/apps/product/modules/custom/tests.py", line 43, in test_custom_product
    self.assertContains(response, "Computer", count=1)
  File "/data/PythonEnvironments/mywebsite.nl/local/lib/python2.7/site-packages/django/test/testcases.py", line 427, in assertContains
    " (expected %d)" % (real_count, text, count))
AssertionError: Found 0 instances of 'Computer' in response (expected 1)

----------------------------------------------------------------------

EDIT 2:
I just discovered the test does not always happen when I put a breakpoint in the requested view function, and wait a while before continuing when the debugger stops at the breakpoint. Maybe this has something to do with threading?

Answer 1

I finally found the solution myself. It had to do something with the caching. Using the dummy cache did solve this specific problem but then another unit test would fail (testCacheGetOK from keyedcache). However, setting the cache timeout to one second during testing solved the problem.