Question

Using the shell, I can do this:

>>> from django.test.client import Client
>>> from django.test.utils import setup_test_environment
>>> setup_test_environment()
>>> c = Client()
>>> c.login(username="dev", password="password")
True
>>> r = c.get('/')
>>> r.status_code
200

Now with this in the test.py file:

from django.test.client import Client

__test__ = {"doctest": """
>>> c = Client()
>>> c.login(username='dev', password='password')
True
>>> r = c.get('/')
>>> r.status_code
200
"""}

I get this output:

Failed example:
    c.login(username="dev", password="password")
Expected:
    True
Got:
    False
------------------------------------------------------
Failed example:
    r.status_code
Expected:
    200
Got:
    302

I’ve looked all over the internet and I can’t find anything that helps with this situation. Any ideas?

On a similar note, I’ve commented out: from django.views.decorators.debug import sensitive_post_parameters and all @sensitive_post_parameters() decorators from my code because each time I run ./manage.py test app django complains:
Could not import app.views. Error was: No module named debug
Removing this decorator and import statement allows it to move forward.

Im very much lost and I need StackOverflow! Thanks everyone.

Answer 1

sensitive_post_parameters is a new feature in Django 1.4, so if you’re running Django 1.3 or earlier then the import will fail.

I believe that the commands you tried in the shell were run on the normal database. When you run your doc tests, Django will set up a test database. It looks like your user dev isn’t in the test database when you run the doc tests, so the login attempt fails. One option is to create the User with User.objects.create_user before you attempt the login. Another option is to use fixtures.

With Django, I would recommend writing unit tests instead of doc tests. One big advantage is that it’s easy to include fixtures to load initial data (e.g. users) into the test database. Another is that Django takes care of refreshing the database between unit tests.