Проблемы с запуском тестов Django и входом в систему тестового клиента с аутентификацией

Используя оболочку, я могу сделать это:

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

Теперь с этим в файле test.py:

from django.test.client import Client

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

Я получаю этот вывод:

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

Я просмотрел весь Интернет, и я не могу найти ничего, что могло бы помочь в этой ситуации. Любые идеи?

Аналогичным образом я закомментировал: from django.views.decorators.debug import sensitive_post_parameters и все декораторы @sensitive_post_parameters() из своего кода, потому что каждый раз, когда я запускаю ./manage.py test app, django жалуется:
Could not import app.views. Error was: No module named debug
Удаление этого декоратора и оператора импорта позволяет ему двигаться дальше.

Я очень растерялся, и мне нужен StackOverflow! Спасибо всем.


django django-testing
person sparrow    schedule 21.02.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

sensitive_post_parameters — это новая функция в Django 1.4, поэтому, если вы используете Django 1.3 или более раннюю версию, импорт не удастся.

Я считаю, что команды, которые вы пробовали в оболочке, выполнялись в обычной базе данных. Когда вы запускаете тесты документации, Django настроит тестовую базу данных. Похоже, что вашего пользователя dev нет в тестовой базе данных, когда вы запускаете тесты документации, поэтому попытка входа не удалась. Один из вариантов — создать пользователя с User.objects.create_user перед попыткой входа в систему. Еще один вариант — использовать светильники.

С Django я бы рекомендовал писать модульные тесты вместо тестов документации. Одним из больших преимуществ является простота включения фикстур для загрузки исходных данных (например, пользователей) в тестовую базу данных. Во-вторых, Django заботится об обновлении базы данных между модульными тестами.

person Alasdair    schedule 21.02.2012
comment
К сожалению, мы используем альфа-версию 1.4, и она отлично работает в производственной среде и среде разработки. Это только кажется, что он терпит неудачу в тестах. Что касается другой проблемы, вы были абсолютно правы. Я добавил пользователя в тестовую базу данных, и все заработало. - person sparrow; 22.02.2012
comment
Может ли ./manage.py test app как-то импортировать старую версию Django? Я знаю, маловероятно, но других идей у ​​меня нет. Рад, что тест заработал. - person Alasdair; 22.02.2012
comment
Итак, получается, что это другая установка django (1.4) на машине, которую apache использовал в качестве виртуальной среды. Поскольку тестовая среда не использует веб-сервер apache для выполнения тестов, использовалась моя локальная установка django (которая была 1.3), и поэтому инструкция импорта не удалась. Еще раз спасибо за указатели. Просто подумал, что обновлю этот вопрос для полноты. - person sparrow; 23.02.2012