Инструменты для тестирования

Django предоставляет несколько инструментов, которые могут быть полезны при написании тестов.

Тестовый клиент

Тестовый клиент – это класс Python, который умеет эмулировать запросы браузера. Он позволяет протестировать ваши представления и программно взаимодействовать с вашим Django-приложением.

Некоторые вещи, которые вы можете делать с тестовым клиентом:

  • Эмулирует GET или POST запросы к URL-у и обрабатывает ответ – начиная от низкоуровневого HTTP (заголовки результата и код ответа) и заканчивая содержимым ответа.

  • Следует по цепочке редиректов (если такие есть) и проверяет URL и код ответа на каждом шаге.

  • Может проверять, что полученный ответ был отрендерен определенным шаблоном Django с контекстом, который содержит определенные переменные.

Обратите внимание, этот клиент не может заменить Selenium или другие фреймворки, которые используют движок браузера для запросов. У тестового клиента Django другие задачи. Если кратко:

  • Вы можете использовать тестовый клиент, если нужно проверить какой шаблон использовался для рендеринга ответа, и какой контекст ему передавался.

  • Фреймворки, которые используют движок браузера, например Selenium, позволяют тестировать уже готовый HTML и поведение страниц в браузере, а именно работу JavaScript. Django предоставляет инструменты для работы с ними, подробности смотрите в описании LiveServerTestCase.

Комплексный набор тестов должен использовать комбинацию обоих типов тестов.

Обзор и примеры

Для использования тестового клиента создайте экземпляр django.test.Client, затем получите страницу:

>>> from django.test import Client
>>> c = Client()
>>> response = c.post('/login/', {'username': 'john', 'password': 'smith'})
>>> response.status_code
200
>>> response = c.get('/customer/details/')
>>> response.content
b'<!DOCTYPE html...'

Как видно из примера, вы можете использовать Client в консоли Python.

Несколько заметок о работе тестового клиента:

  • Для работы тестового клиента не нужно запускать сервер. Он работает непосредственно с Django. Это ускоряет выполнение тестов.

  • Следует указывать путь из URL без домена. Например, вот так правильно:

    >>> c.get('/login/')

    А это не будет работать:

    >>> c.get('https://www.example.com/login/')

    Тестовый клиент умеет получить только те страницы, которые принадлежат текущему Django проекту. Для загрузки внешних страниц можно использовать стандартную библиотеку Python urllib.

  • При обработке URL-ов тестовый клиент использует URLconf указанный в настройке ROOT_URLCONF.

  • Несмотря на то, что примеры выше работают в консоли Python, некоторый функционал тестового клиента, в частности связанный с шаблонизатором, работает только при выполнении тестов.

    Причина в “темной магии”, которую Django использует при запуске тестов для определения какой шаблон был использован представлением. Эта “темная магия” (патчинг системы шаблонов Django в памяти) работает только при выполнении тестов.

  • По умолчанию тестовый клиент отключает все CSRF проверки на вашем проекте.

    Если вы хотите, чтобы тестовый клиент выполнял проверку CSRF, вы можете создать отдельный экземпляр тестового клиента и указать ему выполнять проверку CSRF. Для этого передайте аргумент enforce_csrf_checks в конструктор:

    >>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)

Выполнение запросов

Используйте класс django.test.Client для выполнения запросов.

class Client(enforce_csrf_checks=False, **defaults)

Конструктор не требует обязательных аргументов. Однако, вы можете использовать именованные аргументы, чтобы указать заголовки для запросов. Например, следующий код добавит HTTP заголовок User-Agent для каждого запроса:

>>> c = Client(HTTP_USER_AGENT='Mozilla/5.0')

Значения из аргумента extra, который передается в get(), post(), и т.д., имею более высокий, чем аргументы конструктора.

Аргумент enforce_csrf_checks может использоваться для проверки CSRF (смотрите выше).

Создав экземпляр Client, вы можете использовать следующие методы:

get(path, data=None, follow=False, secure=False, **extra)

Выполняет GET запрос по указанному path и возвращает объект ``Response``(описан ниже).

В словаре data можно передать GET аргументы. Например:

>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7})

...выполнит GET запрос аналогичный:

/customers/details/?name=fred&age=7

Именованные аргументы extra позволяют указать дополнительные HTTP заголовки. Например:

>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7},
...       HTTP_X_REQUESTED_WITH='XMLHttpRequest')

...отправит HTTP заголовок HTTP_X_REQUESTED_WITH, который позволит протестировать обработку django.http.HttpRequest.is_ajax().

Спецификация CGI

Заголовки из **extra должны соответствовать CGI спецификации. Например, различные значения для HTTP заголовка “Host” следует указать в параметре HTTP_HOST.

Если у вас уже есть путь с GET аргументами в URL-кодированном формате, вы можете его использовать без аргумента data. Например, GET запрос из примера выше можно выполнить следующим образом:

>>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')

Если вы передали URL с GET параметрами и передали аргумент data, будет использовать data.

Если передать follow со значением True, тестовый клиент будет следовать всем редиректам и атрибут redirect_chain будет содержать кортеж из всех URL-ов и статусов ответа.

Если у вас есть URL /redirect_me/, который перенаправляет на /next/, который перенаправляет на /final/, вы получите следующее:

>>> response = c.get('/redirect_me/', follow=True)
>>> response.redirect_chain
[('http://testserver/next/', 302), ('http://testserver/final/', 302)]

Если передать secure со значением True, тестовый клиент эмулирует HTTPS запрос.

post(path, data=None, content_type=MULTIPART_CONTENT, follow=False, secure=False, **extra)

Выполняет POST запрос по указанному path и возвращает объект ``Response``(описан ниже).

В словаре data можно передать данные для POST запроса. Например:

>>> c = Client()
>>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})

...выполнит POST запрос на URL:

/login/

...отправив через POST данные:

name=fred&passwd=secret

Если указать content_type (например text/xml для загрузки XML), содержимое data будет отправлено без изменений, используя значение content_type как HTTP заголовок Content-Type.

Если content_type не указан, данные из data будут отправлены с типом multipart/form-data. В этом случае значения из data будут кодированы как “multipart” сообщение и отправлены через POST.

Чтобы отправить несколько значений для одного ключа – например, указать список значений из <select multiple> – укажите список или кортеж значений. Например, следующий data отправит три значения для поля с названием choices:

{'choices': ('a', 'b', 'd')}

Отправка файлов – особый случай. Чтобы отправить файлы через POST запрос, укажите название файлового поля в качестве ключа и открытый файл в качестве значения. Например:

>>> c = Client()
>>> with open('wishlist.doc') as fp:
...     c.post('/customers/wishes/', {'name': 'fred', 'attachment': fp})

(Название attachment взято в качестве примера, используйте название из вашего кода.)

Также можно предоставить любой похожий на файл объект (т.е., StringIO или BytesIO) в качестве файлового дескриптора.

Добавлено в Django 1.8:

Была добавлена возможность использовать файлообразный объект.

Обратите внимание, если вы хотите использовать один файл для нескольких вызовов post(), необходимо явно сбросить указатель текущей позиции файла между вызовами. Самый простой способ – закрыть файл после вызова post(), как это сделано в примере выше.

Вы также должны отрыть файл с возможностью чтения. Если файл содержит бинарные данные, например изображение, необходимо открыть его в режиме rb (бинарное чтение).

Аргумент extra работает так же, как и для Client.get().

Если URL, на который отправляет POST запрос, содержит параметры, они будут доступны через request.GET. Например, при следующем запросе:

>>> c.post('/login/?visitor=true', {'name': 'fred', 'passwd': 'secret'})

... представление, которое обрабатывает запрос, сможет получить имя и пароль из request.POST, и определить был ли пользователь посетителем через request.GET.

Если передать follow со значением True, тестовый клиент будет следовать всем редиректам и атрибут redirect_chain будет содержать кортеж из всех URL-ов и статусов ответа.

Если передать secure со значением True, тестовый клиент эмулирует HTTPS запрос.

head(path, data=None, follow=False, secure=False, **extra)

Выполняет HEAD запрос по указанному path и возвращает объект Response``(описан ниже). Работает как :meth:`Client.get`, включая аргументы ``follow, secure и extra, но ответ без содержимого.

options(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)

Выполняет OPTIONS запрос по указанному path и возвращает объект ``Response``(описан ниже). Удобен при тестировании REST API.

Если передать data, значение будет использовать как тело запроса, а заголовок Content-Type равен content_type.

Аргументы follow, secure и extra работают как и для Client.get().

put(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)

Выполняет PUT запрос по указанному path и возвращает объект ``Response``(описан ниже). Удобен при тестировании REST API.

Если передать data, значение будет использовать как тело запроса, а заголовок Content-Type равен content_type.

Аргументы follow, secure и extra работают как и для Client.get().

patch(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)

Выполняет PATCH запрос по указанному path и возвращает объект ``Response``(описан ниже). Удобен при тестировании REST API.

Аргументы follow, secure и extra работают как и для Client.get().

delete(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)

Выполняет DELETE запрос по указанному path и возвращает объект ``Response``(описан ниже). Удобен при тестировании REST API.

Если передать data, значение будет использовать как тело запроса, а заголовок Content-Type равен content_type.

Аргументы follow, secure и extra работают как и для Client.get().

trace(path, follow=False, secure=False, **extra)
Добавлено в Django 1.8.

Выполняет TRACE запрос по указанному path и возвращает объект Response. Удобен при тестировании.

В отличие от других методов запроса, data не предоставляется в виде именованного параметра для того, чтобы соответствовать RFC 2616, который определяет, что TRACE запросы не должны иметь тела.

Аргументы follow, secure и extra работают как и для Client.get().

login(**credentials)

Если ваш сайт использует систему авторизации Django, вы можете использовать метод login() тестового клиента, чтобы эмулировать авторизацию пользователями.

Неактивного пользователя (is_active=False) нельзя авторизировать т.к. этот метод аналогичен представлению login(), которое использует форму AuthenticationForm и не выполняет авторизацию неактивных пользователей.

После вызова этого метода тестовый клиент будет содержать все куки и данные сессии, которые необходимы, чтобы пройти проверку авторизации в представлении.

Формат аргумента credentials зависит от используемого бэкенда авторизации (который настраивается AUTHENTICATION_BACKENDS). Если вы используете стандартный бэкенд Django (ModelBackend), credentials будет имя и пароль пользователя:

>>> c = Client()
>>> c.login(username='fred', password='secret')

# Now you can access a view that's only available to logged-in users.

Для других бэкендов авторизации параметры могут отличаться. Это зависит от аргументов, которые принимает метод authenticate() бэкенда авторизации.

login() возвращает True, если пользователь успешно залогинен.

Не забудьте создать пользователя перед вызовом метода. Как мы уже сказали выше, тесты используют тестовую базу данных, которая не содержит пользователей по умолчанию. Поэтому пользователь, который существует в вашей базе данных, не будет работать в тестах. Вы должны создать пользователя в текущем наборе тестов явно (используя API Django моделей), или используя тестовые фикстуры. Помните, если вы хотите установить пароль тестовому пользователю, вы не можете этого сделать просто назначив атрибут – вы должны использовать метод set_password(), которая установит пароль в правильно хешированном виде. Также вы можете использовать метод create_user() для создания пользователя с правильным паролем.

force_login(user, backend=None)
Добавлено в Django 1.9.

Если ваш сайт использует систему авторизации Django, вы можете использовать метод force_login() чтобы эмулировать авторизацию пользователя на вашем сайте. Используйте этот метод вместо login(), если необходимо авторизировать пользователя в тестах и при этом не важен способ авторизации.

В отличии от login() этот метод пропускает этапы авторизации и проверки пользователя: неактивные пользователи (is_active=False) могут быть авторизированы и нет надобности указывать данные для авторизации(прим. пер. логин/пароль).

Атрибут backend пользователя будет установлен в значение аргумента backend (которые должен содержать путь для импорта Python), или settings.AUTHENTICATION_BACKENDS[0], если аргумент не указан. Обычно этот атрибут устанавливает функция authenticate(), вызываемая login().

Этот метод быстрее login() т.к. пропускаются сложные алгоритмы хэширования паролей. Также вы можете ускорить login(), используя более простые алгоритмы хэширования паролей.

logout()

Если ваш сайт использует систему авторизации Django, вы можете использовать метод logout() чтобы эмулировать логаут пользователя.

После вызова метода тестовый клиент очистит все куки и сессионные данные. Последующие запросы будт выполнены от AnonymousUser.

Тестовые ответы

Методы get() и post() возвращают объект Response. Этот объект Response отличается от объекта HttpResponse, который возвращается представлениями Django. Тестовый объект ответа содержит дополнительные данные, которые могут быть полезны при тестировании.

Объект Response содержит следующие атрибуты:

class Response
client

Тестовый клиент, который отправил запрос.

content

Содержимое ответа в виде байтовой строки. Окончательное содержимое страницы, которую вернуло представление, или содержимое об ошибке.

context

Экземпляр Context, который использовался при рендеринге шаблона, которые использовался при формировании ответа.

Если использовалось несколько шаблонов, context будет содержать список объектов Context в порядке, котором они использовались при рендеринге.

Независимо от количества используемых шаблонов, значение переменной можно получить с помощью оператора []. Например, получаем значение переменной контекста name:

>>> response = client.get('/foo/')
>>> response.context['name']
'Arthur'

Не используйте шаблоны Django?

Этот атрибут используется только бэкендом DjangoTemplates. Если вы используете другой шаблонизатор, возможно вам поможет context_data.

json(**kwargs)
Добавлено в Django 1.9.

Тело ответа, преобразованное как JSON. Дополнительные именованные аргументы передаются в json.loads(). Например:

>>> response = client.get('/foo/')
>>> response.json()['name']
'Arthur'

Если заголовок Content-Type не "application/json", будет вызвано исключение ValueError, при попытке вызывать этот метод.

request

Запрос, который был отправлен.

wsgi_request

Объект WSGIRequest, который был сгенерирован при отправке запроса.

status_code

HTTP статус ответа, число. Полный список возможных HTTP статусов можно найти в спецификации RFC 2616.

templates

Список объектов Template, которые использовались при формировании ответа, в порядке рендеринга. Название файла шаблона можно получить через атрибут template.name, если шаблон был загружен с файла. (Название будет строкой, например 'admin/index.html'.)

Не используйте шаблоны Django?

Этот атрибут содержит значение только при использовании DjangoTemplates. Если вы используете другой шаблонизатор, возможно вам поможет template_name.

resolver_match
Добавлено в Django 1.8:

Экземпляр класса ResolverMatch для ответа. Вы можете использовать атрибут func, например, для проверки представления, которое выдало ответ:

# my_view here is a function based view
self.assertEqual(response.resolver_match.func, my_view)

# class-based views need to be compared by name, as the functions
# generated by as_view() won't be equal
self.assertEqual(response.resolver_match.func.__name__, MyView.as_view().__name__)

Если указанный URL не найден, доступ к этому атрибуту вызовет исключение Resolver404.

Вы можете использовать синтаксис словаря, чтобы получить значение HTTP заголовков. Например, можно получить тип ответа, используя response['Content-Type'].

Исключения

Если тестовый клиент выполнит запрос к представлению, которые вызывает исключение, исключение будет доступно в тесте. Вы можете использовать стандартный блок try ... except, или assertRaises(), чтобы протестировать исключения.

Единственные исключения, которые не передаются в тест, Http404, PermissionDenied, SystemExit, and SuspiciousOperation. Django перехватывает их и конвертирует в соответствующий код ответа HTTP. В таком случае вы можете проверять response.status_code в тесте.

Сохранение состояния

Тестовый клиент сохраняет состояние между запросами. Если ответ устанавливает куки, они будут сохранены в тестовом клиенте и отправлены в последующих get() и post() запросах.

Клиент не учитывает срок действия кук. Если необходимо удалить куку, делайте это явно, или создайте новый экземпляр Client (таким образом вы удалите все куки).

Клиент хранит состояние в двух атрибутах. Вы можете использовать их в тестах.

Client.cookies

Объект SimpleCookie, который содержит текущие куки клиента. Подробности смотрите в документации модуля http.cookies.

Client.session

Объект с API словаря, который содержит данные сессии. Подробности смотрите в в разделе о сессии.

Используйте переменную, чтобы изменить и сохранить данные сессии (т.к. при каждом обращении к атрибуту создается новый экземпляр SessionStore):

def test_something(self):
    session = self.client.session
    session['somekey'] = 'test'
    session.save()

Пример

Пример простого теста с использованием тестового клиента:

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def setUp(self):
        # Every test needs a client.
        self.client = Client()

    def test_details(self):
        # Issue a GET request.
        response = self.client.get('/customer/details/')

        # Check that the response is 200 OK.
        self.assertEqual(response.status_code, 200)

        # Check that the rendered context contains 5 customers.
        self.assertEqual(len(response.context['customers']), 5)

См.также

django.test.RequestFactory

Базовые классы для создания тестов

Обычно тесты в Python наследуются от unittest.TestCase. Django предоставляет дополнительные классы, которые предоставляют дополнительные возможности:

Hierarchy of Django unit testing classes (TestCase subclasses)

Иерархия классов для тестов в Django

SimpleTestCase

class SimpleTestCase

Наследуется от unittest.TestCase предоставляет некоторые дополнительные возможности:

Если вам нужно больше возможностей Django при тестировании, например:

используйте TransactionTestCase или TestCase.

SimpleTestCase.allow_database_queries
Добавлено в Django 1.9.

SimpleTestCase disallows database queries by default. This helps to avoid executing write queries which will affect other tests since each SimpleTestCase test isn’t run in a transaction. If you aren’t concerned about this problem, you can disable this behavior by setting the allow_database_queries class attribute to True on your test class.

SimpleTestCase наследуется от unittest.TestCase.

Предупреждение

SimpleTestCase и его потомки (т.е., TestCase, ...) используют методы setUpClass() и tearDownClass() для выполнения некоторой инициализации в рамках класса (т.е., для переопределения настроек). Если вам понадобится переопределить эти методы, не забудьте воспользоваться оператором super:

class MyTestCase(TestCase):

    @classmethod
    def setUpClass(cls):
        super(MyTestCase, cls).setUpClass()     # Call parent first
        ...

    @classmethod
    def tearDownClass(cls):
        ...
        super(MyTestCase, cls).tearDownClass()  # Call parent last

TransactionTestCase

class TransactionTestCase

Класс Django TestCase (описан ниже) использует механизм транзакций базы данных для сброса состояния базы данных перед каждым тестом. Но вы не можете тестировать коммит и отмену транзакций Django в классе TestCase. Например, вы не можете проверить, что блок кода выполняется внутри транзакции, как это требуется при использовании метода select_for_update(). В таких случаях, вы должны использовать TransactionTestCase.

Изменено в Django 1.8:

В старых версиях Django, эффекты завершения транзакции и её отката невозможно было протестировать с помощью класса TestCase. Благодаря завершению поддержки старого стиля управления транзакциями в Django 1.8, команды управления транзакциями (такие как transaction.commit()) больше не отключены внутри TestCase.

TransactionTestCase и TestCase отличаются лишь механизмом сброса базы данных перед каждым тестом и мозможностью тестировать транзакции:

  • TransactionTestCase сбрасывает состояние базы данных после выполнения тестам путем очистки всех таблиц. TransactionTestCase позволяет вызывать коммит и отмену транзакций и проверять результат в базе данных.

  • TestCase, в свою очередь, не очищает все таблицы в конце теста. Вместо этого, каждый тест оборачивается в транзакцию, которые откатывается по завершению теста. Это гарантирует, что откат в конце теста вернёт базу данных в начальное состояние.

Предупреждение

TestCase running on a database that does not support rollback (e.g. MySQL with the MyISAM storage engine), and all instances of TransactionTestCase, will roll back at the end of the test by deleting all data from the test database.

Apps will not see their data reloaded; if you need this functionality (for example, third-party apps should enable this) you can set serialized_rollback = True inside the TestCase body.

TransactionTestCase наследуется от SimpleTestCase.

TestCase

class TestCase

This class provides some additional capabilities that can be useful for testing websites.

Преобразовать unittest.TestCase в Django TestCase очень просто: замените базовый класс теста с 'unittest.TestCase' на 'django.test.TestCase'. Все стандартные возможности тестов в Python будут доступны, но в дополнение к ним при запуске теста:

  • Автоматически загружаются фикстуры.

  • Оборачивает тесты двумя atomic блоками: первый для всего класса, а второй для каждого теста.

  • Создается экземпляр тестового клиента.

  • Предоставляются дополнительные возможности для тестирования, такие как проверка перенаправлений, ошибок валидации форм и т.д.

classmethod TestCase.setUpTestData()
Добавлено в Django 1.8.

Описанный выше atomic блок уровня класса позволяет создание начальных данных на уровне класса, один раз для всего TestCase. Такой подход пригодится для быстрых тестов, по сравнению с обычным использованием метода setUp().

Например:

from django.test import TestCase

class MyTests(TestCase):
    @classmethod
    def setUpTestData(cls):
        # Set up data for the whole TestCase
        cls.foo = Foo.objects.create(bar="Test")
        ...

    def test1(self):
        # Some test using self.foo
        ...

    def test2(self):
        # Some other test using self.foo
        ...

Следует отметить, что если тесты запущены на базе данных, у которой нет поддержки транзакций (например, MySQL с движком MyISAM), то метод setUpTestData() будет вызван перед выполнением каждого теста, ухудшая показатели скорости.

Be careful not to modify any objects created in setUpTestData() in your test methods. Modifications to in-memory objects from setup work done at the class level will persist between test methods. If you do need to modify them, you could reload them in the setUp() method with refresh_from_db(), for example.

Предупреждение

Если требуется протестировать специфичное транзакционное поведение базы данных, то вам следует воспользоваться классом TransactionTestCase, так как TestCase оборачивает выполнение теста с помощью блока atomic().

TestCase наследуется от TransactionTestCase.

LiveServerTestCase

class LiveServerTestCase

LiveServerTestCase работает как и TransactionTestCase, но при этом в фоне запускается встроенный сервер Django, который по завершению тестов выключается. Это позволяет использовать клиенты для автоматического тестирования вместо тестового клиента Django, такие как, например, клиент Selenium. С их помощью вы можете создавать функциональные тесты и симулировать реальное поведение пользователей.

By default the live server listens on localhost and picks the first available port in the 8081-8179 range. Its full URL can be accessed with self.live_server_url during the tests.

Изменено в Django 1.9:

In earlier versions, the live server’s default address was always 'localhost:8081'.

If you’d like to select another address then you may pass a different one to the test command via the --liveserver option, for example:

$ ./manage.py test --liveserver=localhost:8082
Изменено в Django 1.9:

In older versions live_server_url could only be accessed from an instance. It now is a class property and can be accessed from class methods like setUpClass().

Еще один способ поменять адрес тестового сервера, установить переменную окружения DJANGO_LIVE_TEST_SERVER_ADDRESS (например в своем классе запуска тестов):

import os
os.environ['DJANGO_LIVE_TEST_SERVER_ADDRESS'] = 'localhost:8082'

Если тесты выполняются в нескольких параллельных процессах (например, при сборке нескольких паралельных билдов), они будут пытаться запустить сервер на одном и том же порте, и могут завершаться с ошибкой “Address already in use”. Чтобы избежать такой проблемы, вы можете указать список портов, разделенных запятой, или диапазон портов (количество портов должно соответствовать количеству предполагаемых параллельных процессов). Например:

$ ./manage.py test --liveserver=localhost:8082,8090-8100,9000-9200,7041

Тогда, при запуске тестов сервер будет перебирать указанные порты, пока не будет найдет свободный.

Чтобы продемонстрировать возможности LiveServerTestCase, давайте напишем простой тест на Selenium. Для начала установите Python пакет selenium:

$ pip install selenium

Then, add a LiveServerTestCase-based test to your app’s tests module (for example: myapp/tests.py). For this example, we’ll assume you’re using the staticfiles app and want to have static files served during the execution of your tests similar to what we get at development time with DEBUG=True, i.e. without having to collect them using collectstatic. We’ll use the StaticLiveServerTestCase subclass which provides that functionality. Replace it with django.test.LiveServerTestCase if you don’t need that.

The code for this test may look as follows:

from django.contrib.staticfiles.testing import StaticLiveServerTestCase
from selenium.webdriver.firefox.webdriver import WebDriver

class MySeleniumTests(StaticLiveServerTestCase):
    fixtures = ['user-data.json']

    @classmethod
    def setUpClass(cls):
        super(MySeleniumTests, cls).setUpClass()
        cls.selenium = WebDriver()

    @classmethod
    def tearDownClass(cls):
        cls.selenium.quit()
        super(MySeleniumTests, cls).tearDownClass()

    def test_login(self):
        self.selenium.get('%s%s' % (self.live_server_url, '/login/'))
        username_input = self.selenium.find_element_by_name("username")
        username_input.send_keys('myuser')
        password_input = self.selenium.find_element_by_name("password")
        password_input.send_keys('secret')
        self.selenium.find_element_by_xpath('//input[@value="Log in"]').click()

Теперь вы можете запустить тесты:

$ ./manage.py test myapp.tests.MySeleniumTests.test_login

Этот тест автоматически откроет Firefox, затем страницу авторизации, вводит логин и пароль и нажимает кнопку “Log in”. Selenium поддерживает и другие драйверы, если у вас не установлен Firefox, или вы хотите использовать другие браузеры. Пример выше показывает лишь малую часть возможностей Selenium; подробности смотрите в документации.

Примечание

При использовании размещённой в оперативной памяти SQLite для выполнения тестов, подключение к базе данных будет использоваться параллельно двумя потоками: в одном потоке работает тестовый сервер, во втором выполняются тесты. Важно, чтобы запросы в разных потоках не выполнялись одновременно, т.к. это может привести к неожиданному поведению тестов. Поэтому вам необходимо убедиться, что разные потоки не обращаются к базе данных одновременно. Для этого в некоторых ситуациях (например, после нажатия на ссылку или отправки формы), вам необходимо дождаться пока Selenium получит ответ от сервера, и загрузится новая страница, затем продолжить выполнение тестов. Вы можете сделать это указав Selenium ждать пока не будет найден тег <body> в ответе (требуется Selenium > 2.13):

def test_login(self):
    from selenium.webdriver.support.wait import WebDriverWait
    timeout = 2
    ...
    self.selenium.find_element_by_xpath('//input[@value="Log in"]').click()
    # Wait until the response is received
    WebDriverWait(self.selenium, timeout).until(
        lambda driver: driver.find_element_by_tag_name('body'))

Проблема в том, что на самом деле нет определенного момента “загрузки страницы”, особенно в современных Web приложениях, которые генерируют HTML динамически после загрузки основы страницы с сервера. Поэтому ожидание тега <body> не подходит для всех случаев. Дополнительную информацию ищите в Selenium FAQ и документации Selenium.

Возможности приложения для тестирования

Тестовый клиент по умолчанию

SimpleTestCase.client

Каждый тест экземпляра django.test.*TestCase может использовать экземпляр тестового клиента Django, обратившись к атрибуту self.client. Этот клиент пересоздается для каждого теста, поэтому вам не нужно беспокоится о состоянии (например о куках) между тестами.

Поэтому вместо создания экземпляра Client в каждом тесте:

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def test_details(self):
        client = Client()
        response = client.get('/customer/details/')
        self.assertEqual(response.status_code, 200)

    def test_index(self):
        client = Client()
        response = client.get('/customer/index/')
        self.assertEqual(response.status_code, 200)

...вы можете просто обращаться к self.client:

from django.test import TestCase

class SimpleTest(TestCase):
    def test_details(self):
        response = self.client.get('/customer/details/')
        self.assertEqual(response.status_code, 200)

    def test_index(self):
        response = self.client.get('/customer/index/')
        self.assertEqual(response.status_code, 200)

Переопределение тестового клиента

SimpleTestCase.client_class

Если вы хотите использовать переопределенный класс Client, укажите его в атрибуте client_class:

from django.test import TestCase, Client

class MyTestClient(Client):
    # Specialized methods for your environment
    ...

class MyTest(TestCase):
    client_class = MyTestClient

    def test_my_stuff(self):
        # Here self.client is an instance of MyTestClient...
        call_some_test_code()

Загрузка фикстур

TransactionTestCase.fixtures

A test case for a database-backed website isn’t much use if there isn’t any data in the database. To make it easy to put test data into the database, Django’s custom TransactionTestCase class provides a way of loading fixtures.

Фикстуры - это набор данных, которые Django умеет импортировать в базу данных. Например, если ваш сайт использует модель пользователя, вы можете создать фикстуру с данными пользователей и загружать её перед запуском тестов.

Самый простой способ создать фикстуры, использовать команду manage.py dumpdata. Необходимые данные должны быть в вашей базе данных. Подробности смотрите в описании команды dumpdata.

После создания фикстур, добавьте их в каталог fixtures одного из ваших приложений из INSTALLED_APPS. Теперь вы можете использовать их в тестах, указав в атрибуте fixtures класса-наследника django.test.TestCase:

from django.test import TestCase
from myapp.models import Animal

class AnimalTestCase(TestCase):
    fixtures = ['mammals.json', 'birds']

    def setUp(self):
        # Test definitions as before.
        call_setup_methods()

    def testFluffyAnimals(self):
        # A test that uses the fixtures.
        call_some_test_code()

Что произойдет:

  • Перед выполнение теста и перед методом setUp(), Django очитсти базу данных и вернет её до состояния после выполнения команды migrate.

  • Затем загружаются фикстуры. В примере выше Django загрузит JSON фикстуру с названием mammals, затем фикстуру birds. Подробности смотрите в описании loaddata.

Перезагрузка фикстур выполняет перед каждым тестом, вы можете не беспокоится, что один тест повлияет на выполнение другого.

По умолчанию фикстуры загружаются в базу данных default. Если вы используете несколько баз данных и указали атрибут multi_db=True, фикстуры будут загружены в несколько баз данных.

Конфигурация URLconf

SimpleTestCase.urls

Не рекомендуется, начиная с версии 1.8: Вместо этого используйте @override_settings(ROOT_URLCONF=...) для настройки схемы URL.

Если выше приложение содержит представления, вам понадобятся тесты, которые вызывают их, используя тестовый клиент. Однако, пользователь приложения может добавить представления на любой URL. Это означает, что тесты не могут полагаться на то, что представление доступно по определенному URL-у.

Чтобы обеспечить определенность URL-ов в тестах, классы django.test.*TestCase предоставляют возможность настроить URLconf для теста. Если атрибут urls экземпляра *TestCase содержит конфигурацию URL-ов, *TestCase будет использовать ее как значение ROOT_URLCONF при выполнении тестов.

Например:

from django.test import TestCase

class TestMyViews(TestCase):
    urls = 'myapp.test_urls'

    def test_index_page_view(self):
        # Here you'd test your view using ``Client``.
        call_some_test_code()

При выполнении этого теста содержимое myapp.test_urls будет использоваться как URLconf.

Поддержка нескольких баз данных

TransactionTestCase.multi_db

Django создает тестовую базу для каждой указанной базы данных из настройки DATABASES. Однако, большую часть времени выполнения тестов занимает операция очистки базы данных(flush) перед каждым тестом. Если вы используете несколько баз данных, требуется несколько операций flush (одна на каждую базу денных). Это может заниматься достаточно много времени.

Для оптимизации Django очищает только базу данных default перед каждым тестом. Если ваш проект использует несколько баз данных, и в перед тестом необходимо очищать все базы данных, вы можете указать атрибут multi_db для класса тестов.

Например:

class TestMyViews(TestCase):
    multi_db = True

    def test_index_page_view(self):
        call_some_test_code()

This test case will flush all the test databases before running test_index_page_view.

Флаг multi_db также определяет в какую базу данных будет загружены фикстуры из TransactionTestCase.fixtures. По умолчанию (при multi_db=False) фикстуры загружаются только в базу данных default. При multi_db=True фикстуры загружаются во все базы данных.

Переопределение настроек

Предупреждение

Используйте приведённые ниже функции для временного изменения значения параметров конфигурации в тестах. Не изменяйте django.conf.settings напрямую, так как Django не восстановит оригинальные значения после таких манипуляций.

SimpleTestCase.settings()

При тестировании часто необходимо временно переопределить настройки и вернуть начальные значение после завершения тестов. Для таких случаев Django предоставляет стандартный контекстный менеджер Python (смотрите PEP 343), который называется settings(). Его можно использовать следующим образом:

from django.test import TestCase

class LoginTestCase(TestCase):

    def test_login(self):

        # First check for the default behavior
        response = self.client.get('/sekrit/')
        self.assertRedirects(response, '/accounts/login/?next=/sekrit/')

        # Then override the LOGIN_URL setting
        with self.settings(LOGIN_URL='/other/login/'):
            response = self.client.get('/sekrit/')
            self.assertRedirects(response, '/other/login/?next=/sekrit/')

В этом примере мы переопределили LOGIN_URL для блока with, после выхода из блока настройка будет сброшена.

SimpleTestCase.modify_settings()

Помогает при переопределении настроек, которые содержат список. Если вам необходимо добавить или удалить значение из списка, используйте контекстный менеджер modify_settings():

from django.test import TestCase

class MiddlewareTestCase(TestCase):

    def test_cache_middleware(self):
        with self.modify_settings(MIDDLEWARE_CLASSES={
            'append': 'django.middleware.cache.FetchFromCacheMiddleware',
            'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
            'remove': [
                'django.contrib.sessions.middleware.SessionMiddleware',
                'django.contrib.auth.middleware.AuthenticationMiddleware',
                'django.contrib.messages.middleware.MessageMiddleware',
            ],
        }):
            response = self.client.get('/')
            # ...

Для каждого действия вы можете указать список значений или строку. Если значение уже в списке, append и prepend не имеют никакого эффекта; аналогично remove ничего не сделает, если значение отсутствует в списке.

override_settings()

Если вы хотите переопределить настройки для тестового метода, Django предоставляет декоратор override_settings() (смотрите PEP 318). Вы можете использовать его следующим образом:

from django.test import TestCase, override_settings

class LoginTestCase(TestCase):

    @override_settings(LOGIN_URL='/other/login/')
    def test_login(self):
        response = self.client.get('/sekrit/')
        self.assertRedirects(response, '/other/login/?next=/sekrit/')

Декоратор можно применять и к классам TestCase:

from django.test import TestCase, override_settings

@override_settings(LOGIN_URL='/other/login/')
class LoginTestCase(TestCase):

    def test_login(self):
        response = self.client.get('/sekrit/')
        self.assertRedirects(response, '/other/login/?next=/sekrit/')
modify_settings()

Также Django содержит декоратор modify_settings():

from django.test import TestCase, modify_settings

class MiddlewareTestCase(TestCase):

    @modify_settings(MIDDLEWARE_CLASSES={
        'append': 'django.middleware.cache.FetchFromCacheMiddleware',
        'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
    })
    def test_cache_middleware(self):
        response = self.client.get('/')
        # ...

Его можно применять к классам с тестами:

from django.test import TestCase, modify_settings

@modify_settings(MIDDLEWARE_CLASSES={
    'append': 'django.middleware.cache.FetchFromCacheMiddleware',
    'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
})
class MiddlewareTestCase(TestCase):

    def test_cache_middleware(self):
        response = self.client.get('/')
        # ...

Примечание

Эти декораторы непосредственно изменяют класс, они не создают и возвращают копию. Если вы попытаетесь назначить возвращаемый результат переменным с названиями отличными от LoginTestCase илиr MiddlewareTestCase, вы обнаружите, что оригинальные классы были все равно изменены декораторами. Декоратор modify_settings() всегда применяет после override_settings(), если их добавить к одному классу.

Предупреждение

Файл настроек содержит некоторые настройки, которые используются только при инициализации Django. Если вы измените их с помощью override_settings, настройка измениться, если получить значение из модуля django.conf.settings, однако Django может обращаться к ней по другому. Поэтому override_settings() или modify_settings() могут работать не так, как вы ожидаете .

Мы не советуем изменять настройку DATABASES. Менять CACHES можно, но требует дополнительных действий, если кеш используется другими механизмами Django, например django.contrib.sessions. В таком случае вам понадобиться заново инициализировать сессию в тесте после изменения CACHES.

Также не указывайте ваши настройки в константах модуля, override_settings() не будет работать с такими настройками т.к. они выполняются только при первом импорте модуля. (FIXME: whut?)

Вы также можете протестировать отсутствие настройки, удалив ее после использования декоратора:

@override_settings()
def test_something(self):
    del settings.LOGIN_URL
    ...

При переопределении настроек учитывайте ситуации, когда выше приложение использует кеш или другие механизмы, которые сохраняют свое состояние после изменения настроек. Django предоставляет сигнал django.test.signals.setting_changed, который позволяет сбросить состояние, или выполнить другие действия, при изменении настроек.

Django использует этот сигнал для сброса различных данных:

Переопределенные настройки

Данные, который сбрасываются
USE_TZ, TIME_ZONE

Часовой пояс баз данных
TEMPLATES

Шаблонные движки
SERIALIZATION_MODULES

Кеш сериализаторов
LOCALE_PATHS, LANGUAGE_CODE

Перевод по умолчанию и загруженные переводы
MEDIA_ROOT, DEFAULT_FILE_STORAGE

Хранилище файлов по умолчанию

Очистка тестовых электронных писем

Если вы используйте класс TestCase Django, содержимое отправленных тестовых электронных писем будет очищено перед каждым тестом.

Подробности смотрите ниже в разделе об отправке писем.

Проверки

Кроме стандартных методов для проверки, которые предоставляет стандартный класс unittest.TestCase, например assertTrue() и assertEqual(), TestCase Django предоставляет дополнительные методы для проверки, которые могут быть полезны при тестировании Web приложений:

Сообщения об ошибки можно переопределить аргументом msg_prefix для большинства методов проверки. Указанная строка будет добавлена к каждому сообщению об ошибке. Это позволяет указать вам дополнительную информацию, которая поможет определить какой тест не прошел и причину ошибки.

SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable, *args, **kwargs)
SimpleTestCase.assertRaisesMessage(expected_exception, expected_message)

Asserts that execution of callable raises expected_exception and that expected_message is found in the exception’s message. Any other outcome is reported as a failure. Similar to unittest’s assertRaisesRegex() with the difference that expected_message isn’t a regular expression.

If only the expected_exception and expected_message parameters are given, returns a context manager so that the code being tested can be written inline rather than as a function:

with self.assertRaisesMessage(ValueError, 'invalid literal for int()'):
    int('a')

Не рекомендуется, начиная с версии 1.9: Passing callable as a keyword argument called callable_obj is deprecated. Pass the callable as a positional argument instead.

SimpleTestCase.assertFieldOutput(fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value='')

Проверяет поведение поля формы с разными значениями.

Параметры:
  • fieldclass – класс поля, который тестируется.
  • valid – словарь, который указывает передаваемые значение и ожидаемые после проверки.
  • invalid – словарь, который указывает неправильные входные значения и ожидаемые ошибки валидации.
  • field_args – позиционные аргументы, которые передаются при создании поля.
  • field_kwargs – именованные аргументы, которые передаются при создании поля.
  • empty_value – ожидаемое значение после проверки для входящих пустых значений из empty_values.

Например, следующий код проверяет, что поле EmailField принимает a@a.com как правильное значение, но возвращает ошибки, если передать aaa:

self.assertFieldOutput(EmailField, {'a@a.com': 'a@a.com'}, {'aaa': ['Enter a valid email address.']})
SimpleTestCase.assertFormError(response, form, field, errors, msg_prefix='')

Проверяет, что поле формы из ответа содержит указанный список ошибок.

form – название экземпляра Form в контексте шаблона ответа.

field – название поля формы. Если field содержит None, будут проверятся ошибки не привязанные к конкретному полю (которые можно получить с помощью метода form.non_field_errors()).

errors – строка с ошибкой, или список ошибок, которые были получены при валидации формы.

SimpleTestCase.assertFormsetError(response, formset, form_index, field, errors, msg_prefix='')

Проверяет, что formset из ответа содержит указанный список ошибок.

formset – название экземпляра Formset в контексте шаблона ответа.

form_index – номер формы в Formset. Если form_index содержит None, будут проверятся ошибки не привязанные к конкретной форме (которые можно получить с помощью метода formset.non_form_errors()).

field – название поля формы. Если field содержит None, будут проверятся ошибки не привязанные к конкретному полю (которые можно получить с помощью метода form.non_field_errors()).

errors – строка с ошибкой, или список ошибок, которые были получены при валидации формы.

SimpleTestCase.assertContains(response, text, count=None, status_code=200, msg_prefix='', html=False)

Проверяет, что объект Response с указанным status_code и содержит text. Если указан count, text должен встречаться count раз в ответе.

Укажите True в html, чтобы text обрабатывался как HTML. Сравнение содержимого будет основано на семантике HTML, а не посимвольном сравнении. Пробелы будут проигнорированы в большинстве случаев, порядок атрибутов не учитывается. Подробности с мотрите в описании assertHTMLEqual().

SimpleTestCase.assertNotContains(response, text, status_code=200, msg_prefix='', html=False)

Asserts that a Response instance produced the given status_code and that text does not appear in the content of the response.

Укажите True в html, чтобы text обрабатывался как HTML. Сравнение содержимого будет основано на семантике HTML, а не посимвольном сравнении. Пробелы будут проигнорированы в большинстве случаев, порядок атрибутов не учитывается. Подробности с мотрите в описании assertHTMLEqual().

SimpleTestCase.assertTemplateUsed(response, template_name, msg_prefix='', count=None)

Проверяет, что указанный шаблон использовался при рендеринге ответа.

Название – строка, например 'admin/index.html'.

Добавлено в Django 1.8:

Количество аргументов - это целое, показывающее количество раз, которое будет обработан шаблон. По умолчанию это None, означающее, что шаблон должен быть обработан один или борее раз.

Можно использовать как менеджер контекста:

with self.assertTemplateUsed('index.html'):
    render_to_string('index.html')
with self.assertTemplateUsed(template_name='index.html'):
    render_to_string('index.html')
SimpleTestCase.assertTemplateNotUsed(response, template_name, msg_prefix='')

Проверяет, что указанный шаблон не использовался при рендеринге ответа.

Можно использовать как менеджер контекста, как и assertTemplateUsed().

SimpleTestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200, msg_prefix='', fetch_redirect_response=True)

Проверяет, что status_code ответа указывает на редирект на expected_url (включая GET параметры), и финальная страница загружается со статусом target_status_code.

Если запрос использует аргумент follow, expected_url и target_status_code будут указывать на последний запрос.

Если fetch_redirect_response равен False, последняя страница не будет загружена. Т.к. тестовый клиент не загружает внешние URL-ы, этот аргумент полезен, если expected_url указывает на внешний URL.

Протокол правильно обрабатывается при сравнении URL-ов. Если протокол не указан при редиректе, будет использоваться протокол изначального запроса.

Не рекомендуется, начиная с версии 1.9: The host argument is deprecated, as redirections are no longer forced to be absolute URLs.

SimpleTestCase.assertHTMLEqual(html1, html2, msg=None)

Сравнивает строки html1 и html2. Сравнение основано на семантике HTML. При сравнении используются следующие правила:

  • Пробелы перед и после HTML тегов игнорируются.

  • Все типы пробелов считаются одинаковыми.

  • Все незакрытые теги закрываются, например, при закрытии внешнего тега, или в конце HTML документа.

  • Пустые теги равны самозакрывающиемся аналогичным тегам.

  • Порядок атрибутов HTML тегов не учитывается.

  • Атрибуты без значений равны атрибутам, значение которых равно названию атрибута (смотрите примеры).

Следующие тесты не вызывают AssertionError:

self.assertHTMLEqual(
    '<p>Hello <b>world!</p>',
    '''<p>
        Hello   <b>world! <b/>
    </p>'''
)
self.assertHTMLEqual(
    '<input type="checkbox" checked="checked" id="id_accept_terms" />',
    '<input id="id_accept_terms" type="checkbox" checked>'
)

html1 и html2 должны содержать правильный HTML. Если один из них не будет отпарсен, метод вызовет исключение AssertionError.

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)

Проверяет, что строки html1 и html2 отличаются. Сравнение основано на семантике HTML. Подробности смотрите в описании assertHTMLEqual().

html1 и html2 должны содержать правильный HTML. Если один из них не будет отпарсен, метод вызовет исключение AssertionError.

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None)

Проверяет, что строки xml1 и xml2 одинаковы. При сравнении используется семантика XML. Как и в assertHTMLEqual(), сравнивается результат парсинка, то есть учитываются только семантические отличия, а не отличия в синтаксисе. Если передан не правильный XML, вызывается AssertionError, даже если обе строки одинаковы.

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None)

Проверяет, что строки xml1 и xml2 не одинаковы. При сравнении используется семантика XML. Подробности смотрите в описании assertXMLEqual().

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='')

Проверяет наличие HTML фрагмента needle в haystack.

Если указан параметр count, проверяется, что needle встречается указанное число раз.

В большинстве случаев пробелы игнорируются. Аргументы должны содержать правильный HTML.

SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None)

Проверяет, что JSON в raw и expected_data одинаковый. Обработка пробелов в JSON делегируется библиотеке json.

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None)
Добавлено в Django 1.8.

Проверяет, что фрагменты JSON raw и expected_data не одинаковы. Подробности смотрите в описании assertJSONEqual().

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

TransactionTestCase.assertQuerysetEqual(qs, values, transform=repr, ordered=True, msg=None)

Проверяет, что qs``(объект ``QuerySet) возвращает список значений values.

При сравнении содержимого qs и values используется функция transform; по умолчанию сравнивается результат repr() над каждым значением. Вы можете указать другую функцию, если repr() возвращает не уникальные значения, которые нельзя использовать при сравнении.

По умолчанию, при сравнении учитывается и порядок значений. Если qs не содержит неявных правил сортировки, вы можете указать False в ordered, что преобразует сравнение в сравнение collections.Counter. Если же порядок не определён (если переданная qs не отсортирована и сравнение сравнение производится по нескольким отсортированным значениям), то вызывается исключение ValueError.

Вы можете изменить сообщение об ошибке с помощью аргумента msg.

TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)

Проверяет, что при вызове функции func с аргументами *args и **kwargs выполнилось num запросов в базу данных.

Если kwargs содержит ключ "using", он используется для определения базы данных, для которой необходимо считать количество запросов. Если вы хотите вызывать функцию с аргументом using, оберните её в lambda, чтобы добавить аргумент:

self.assertNumQueries(7, lambda: my_function(using=7))

Вы можете использовать этот метод как менеджер контекста:

with self.assertNumQueries(2):
    Person.objects.create(name="Aaron")
    Person.objects.create(name="Daniel")

Сервисы для отправки писем

Если выши представления оправляют электронные письма, используя встроенный функционал Django, вы, скорее всего, не захотите, чтобы они отправлялись при каждом запуске тестов. В таких случаях Django автоматически перенаправляет все письма, отправленные через механизм Django, в специальную переменную в памяти. Это позволяет тестировать отправку писем без реальной отправки.

Django неявно подменяет бэкенд для отправки писем при запуске тестов. (Не беспокойтесь – это распространяется только на Django. Если вы используете локальные почтовые сервисы, они будут работь без изменений.)

django.core.mail.outbox

При выполнении тестов все отправленные письма сохраняются в переменной django.core.mail.outbox. Это просто список объектов EmailMessage писем, которые были отправлены. Атрибут outbox создается только для locmem бэкенда отправки писем. Вы не можете импортировать его из модуля django.core.mail. Пример ниже показывает как следует его использовать.

Этот пример проверяет размер и содержимое django.core.mail.outbox:

from django.core import mail
from django.test import TestCase

class EmailTest(TestCase):
    def test_send_email(self):
        # Send message.
        mail.send_mail('Subject here', 'Here is the message.',
            'from@example.com', ['to@example.com'],
            fail_silently=False)

        # Test that one message has been sent.
        self.assertEqual(len(mail.outbox), 1)

        # Verify that the subject of the first message is correct.
        self.assertEqual(mail.outbox[0].subject, 'Subject here')

Как упоминалось выше, содержимое этого атрибута очищается при запуске каждого теста из *TestCase. Чтобы явно очистить – просто укажите пустой список в mail.outbox:

from django.core import mail

# Empty the test outbox
mail.outbox = []

Команды управления

Команды управления могут быть протестированы с помощью функции call_command(). Вывод может быть перенаправлен в объект StringIO:

from django.core.management import call_command
from django.test import TestCase
from django.utils.six import StringIO

class ClosepollTest(TestCase):
    def test_command_output(self):
        out = StringIO()
        call_command('closepoll', stdout=out)
        self.assertIn('Expected output', out.getvalue())

Пропуск тестов

Библиотека unittest предоставляет декораторы @skipIf и @skipUnless, которые позволяют пропускать тесты, если вы знаете, что они не выполнятся успешно при определенных условиях.

Например, если ваш тест требует определенной необязательной библиотеки, вы можете обернуть тест декоратором @skipIf. Тест будет пропущен, будет выведена причина пропуска.

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

Декораторы используют строковые называние возможностей базы данных. Строка соответствует атрибуту из класса django.db.backends.BaseDatabaseFeatures, смотрите описание класса, чтобы узнать полный список возможностей базы данных, которые можно проверять.

skipIfDBFeature(*feature_name_strings)

Пропускает декорируемый тест или TestCase, если поддерживаются все указанные возможности базы данных.

Например, следующий тест будет пропущен, если база данных поддерживает транзакции (например, он не будет выполнятся на PostgreSQL, но выполниться на MySQL с таблицами MyISAM):

class MyTests(TestCase):
    @skipIfDBFeature('supports_transactions')
    def test_transaction_behavior(self):
        # ... conditional test code
        pass
Изменено в Django 1.8:

skipIfDBFeature может принимать строку, описывающую несколько возможностей.

skipUnlessDBFeature(*feature_name_strings)

Пропускает декорируемый тест или TestCase, если не поддерживается любая из перечисленных возможностей базы данных.

Например, следующий тест выполнится, если база данных поддерживает транзакции (например, он выполниться на PostgreSQL, но не на MySQL с таблицами MyISAM):

class MyTests(TestCase):
    @skipUnlessDBFeature('supports_transactions')
    def test_transaction_behavior(self):
        # ... conditional test code
        pass
Изменено в Django 1.8:

skipUnlessDBFeature может принимать строку, описывающую несколько возможностей базы данных.

« previous | up | next »