Дополнительные темы тестирования

Фабрика запросов

class RequestFactory [исходный код]

RequestFactory предоставляет тот же API, что и тестовый клиент. Однако, вместо того чтобы вести себя как браузер, RequestFactory позволяет создать экземпляр запроса, который можно использовать в качестве первого аргумента любого представления. Это значит, что вы можете тестировать функцию-представление так же, как любую другую функцию, — как чёрный ящик с точно известными входными данными и проверкой определённых выходных данных.

API RequestFactory представляет собой несколько ограниченное подмножество API тестового клиента:

• Доступны только HTTP-методы get(), post(), put(), delete(), head(), options() и trace().
• Эти методы принимают те же аргументы, кроме follow. Поскольку это всего лишь фабрика запросов, обрабатывать ответ вам придётся самостоятельно.
• Поддержка промежуточного ПО отсутствует. Если представлению для корректной работы необходимы атрибуты сеанса и аутентификации, их должен предоставить сам тест.

from django.contrib.auth.models import AnonymousUser, User
from django.test import RequestFactory, TestCase

from .views import MyView, my_view


class SimpleTest(TestCase):
    def setUp(self):
        # Every test needs access to the request factory.
        self.factory = RequestFactory()
        self.user = User.objects.create_user(
            username="jacob", email="jacob@…", password="top_secret"
        )

    def test_details(self):
        # Create an instance of a GET request.
        request = self.factory.get("/customer/details")

        # Recall that middleware are not supported. You can simulate a
        # logged-in user by setting request.user manually.
        request.user = self.user

        # Or you can simulate an anonymous user by setting request.user to
        # an AnonymousUser instance.
        request.user = AnonymousUser()

        # Test my_view() as if it were deployed at /customer/details
        response = my_view(request)
        # Use this syntax for class-based views.
        response = MyView.as_view()(request)
        self.assertEqual(response.status_code, 200)

Тестирование представлений на основе классов

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

Например, предположим, что имеется следующее представление на основе класса:

from django.views.generic import TemplateView


class HomeView(TemplateView):
    template_name = "myapp/home.html"

    def get_context_data(self, **kwargs):
        kwargs["environment"] = "Production"
        return super().get_context_data(**kwargs)

Вы можете напрямую протестировать метод get_context_data(): сначала создайте экземпляр представления, затем передайте request в setup() и после этого выполните код теста:

from django.test import RequestFactory, TestCase
from .views import HomeView


class HomePageTest(TestCase):
    def test_environment_set_in_context(self):
        request = RequestFactory().get("/")
        view = HomeView()
        view.setup(request)

        context = view.get_context_data()
        self.assertIn("environment", context)

Тесты и несколько имён хостов

При запуске тестов проверяется параметр ALLOWED_HOSTS. Это позволяет тестовому клиенту отличать внутренние URL от внешних.

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

Первый способ — добавить хосты в файл настроек. Например, набор тестов для docs.djangoproject.com включает следующее:

from django.test import TestCase


class SearchFormTestCase(TestCase):
    def test_empty_get(self):
        response = self.client.get(
            "/en/dev/search/",
            headers={"host": "docs.djangoproject.dev:8000"},
        )
        self.assertEqual(response.status_code, 200)

а файл настроек содержит список доменов, поддерживаемых проектом:

ALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]

Другой способ — добавить необходимые хосты в ALLOWED_HOSTS с помощью override_settings() или modify_settings. Этот способ может быть предпочтительнее для автономных приложений, которые не могут включить в свой пакет собственный файл настроек, или для проектов с динамическим списком доменов (например, поддоменов для мультитенантности). Например, тест для домена http://otherserver/ можно написать так:

from django.test import TestCase, override_settings


class MultiDomainTestCase(TestCase):
    @override_settings(ALLOWED_HOSTS=["otherserver"])
    def test_other_domain(self):
        response = self.client.get("http://otherserver/foo/bar/")

Отключение проверки ALLOWED_HOSTS (ALLOWED_HOSTS = ['*']) при запуске тестов не позволяет тестовому клиенту вывести полезное сообщение об ошибке, если вы переходите по перенаправлению на внешний URL.

Тесты и несколько баз данных

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": "myproject",
        "HOST": "dbprimary",
        # ... plus some other settings
    },
    "replica": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": "myproject",
        "HOST": "dbreplica",
        "TEST": {
            "MIRROR": "default",
        },
        # ... plus some other settings
    },
}

DATABASES = {
    "default": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds"],
        },
    },
    "diamonds": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": [],
        },
    },
    "clubs": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds"],
        },
    },
    "spades": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds", "hearts"],
        },
    },
    "hearts": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds", "clubs"],
        },
    },
}

Дополнительные возможности TransactionTestCase

TransactionTestCase.available_apps

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

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

Он используется для оптимизации собственного набора тестов Django, содержащего сотни моделей, но не содержащего связей между моделями из разных приложений.

По умолчанию available_apps имеет значение None. После каждого теста Django вызывает flush, чтобы сбросить состояние базы данных. Эта команда очищает все таблицы и отправляет сигнал post_migrate, который создаёт один тип содержимого и четыре разрешения для каждой модели. Эта операция становится тем затратнее, чем больше моделей.

Если присвоить available_apps список приложений, Django будет вести себя так, словно доступны только модели из этих приложений. Поведение TransactionTestCase изменится следующим образом:

• Перед каждым тестом отправляется сигнал post_migrate, чтобы создать типы содержимого и разрешения для каждой модели в доступных приложениях, если они отсутствуют.
• После каждого теста Django очищает только таблицы, соответствующие моделям доступных приложений. Однако на уровне базы данных усечение может каскадно затронуть связанные модели из недоступных приложений. Кроме того, сигнал post_migrate не отправляется; он будет отправлен при следующем TransactionTestCase после выбора правильного набора приложений.

Поскольку база данных не очищается полностью, если тест создаёт экземпляры моделей, не включённых в available_apps, они сохранятся и могут привести к сбою других тестов. Будьте осторожны с тестами, использующими сеансы: по умолчанию механизм сеансов хранит их в базе данных.

Поскольку после очистки базы данных сигнал post_migrate не отправляется, после TransactionTestCase её состояние отличается от состояния после TestCase: в ней отсутствуют строки, созданные обработчиками сигнала post_migrate. С учётом порядка выполнения тестов это не имеет значения, если либо все TransactionTestCase в наборе тестов объявляют available_apps, либо ни один из них этого не делает.

В собственном наборе тестов Django использование available_apps обязательно.

TransactionTestCase.reset_sequences

Если установить reset_sequences = True для TransactionTestCase, последовательности будут сбрасываться перед каждым запуском теста:

class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):
    reset_sequences = True

    def test_animal_pk(self):
        lion = Animal.objects.create(name="lion", sound="roar")
        # lion.pk is guaranteed to always be 1
        self.assertEqual(lion.pk, 1)

Если вы специально не тестируете значения последовательности первичных ключей, рекомендуется не задавать их значения в тестах жёстко.

Использование reset_sequences = True замедлит тест, поскольку сброс первичного ключа — относительно затратная операция с базой данных.

Принудительное последовательное выполнение классов тестов

Если у вас есть классы тестов, которые нельзя запускать параллельно (например, из-за использования общего ресурса), можно воспользоваться django.test.testcases.SerializeMixin, чтобы запускать их последовательно. Этот миксин использует файловую lockfile.

Например, с помощью __file__ можно задать последовательный запуск всех классов тестов в одном файле, наследующих SerializeMixin:

import os

from django.test import TestCase
from django.test.testcases import SerializeMixin


class ImageTestCaseMixin(SerializeMixin):
    lockfile = __file__

    def setUp(self):
        self.filename = os.path.join(temp_storage_dir, "my_file.png")
        self.file = create_file(self.filename)


class RemoveImageTests(ImageTestCaseMixin, TestCase):
    def test_remove_image(self):
        os.remove(self.filename)
        self.assertFalse(os.path.exists(self.filename))


class ResizeImageTests(ImageTestCaseMixin, TestCase):
    def test_resize_image(self):
        resize_image(self.file, (48, 48))
        self.assertEqual(get_image_size(self.file), (48, 48))

Использование средства запуска тестов Django для тестирования повторно используемых приложений

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

Обычно рядом с кодом приложения создают каталог tests со следующей структурой:

runtests.py
polls/
    __init__.py
    models.py
    ...
tests/
    __init__.py
    models.py
    test_settings.py
    tests.py

Рассмотрим содержимое нескольких файлов:

#!/usr/bin/env python
import os
import sys

import django
from django.conf import settings
from django.test.utils import get_runner

if __name__ == "__main__":
    os.environ["DJANGO_SETTINGS_MODULE"] = "tests.test_settings"
    django.setup()
    TestRunner = get_runner(settings)
    test_runner = TestRunner()
    failures = test_runner.run_tests(["tests"])
    sys.exit(bool(failures))

Этот скрипт запускает набор тестов. Он настраивает окружение Django, создаёт тестовую базу данных и запускает тесты.

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

SECRET_KEY = "fake-key"
INSTALLED_APPS = [
    "tests",
]

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

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

Поскольку при запуске тестов пакет tests включён в INSTALLED_APPS, в его файле models.py можно объявлять модели, предназначенные только для тестов.

Использование различных фреймворков для тестирования

Очевидно, unittest — не единственный фреймворк для тестирования Python. Хотя Django не обеспечивает явной поддержки альтернативных фреймворков, он позволяет запускать тесты, созданные для альтернативного фреймворка, так, как если бы это были обычные тесты Django.

При запуске ./manage.py test Django проверяет настройку TEST_RUNNER, чтобы определить, что делать. По умолчанию TEST_RUNNER указывает на 'django.test.runner.DiscoverRunner'. Этот класс определяет поведение Django при тестировании по умолчанию. Оно включает в себя:

1. Выполнение общей предварительной настройки перед тестами.
2. Поиск тестов в любом файле ниже текущего каталога, имя которого соответствует шаблону test*.py.
3. Создание тестовых баз данных.
4. Запуск migrate для установки моделей и начальных данных в тестовые базы данных.
5. Запуск системных проверок.
6. Запуск найденных тестов.
7. Удаление тестовых баз данных.
8. Выполнение общей заключительной очистки после тестов.

Если вы определите собственный класс запуска тестов и укажете его в настройке TEST_RUNNER, Django будет запускать этот класс каждый раз, когда вы выполняете ./manage.py test. Таким образом, можно использовать любой фреймворк тестирования, который можно запустить из кода Python, или изменить процесс выполнения тестов Django в соответствии с вашими требованиями.

Интеграция с coverage.py

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

Django легко интегрируется с coverage.py — инструментом для измерения покрытия кода программ Python. Сначала установите coverage. Затем из папки проекта, содержащей manage.py, выполните следующую команду:

coverage run --source='.' manage.py test myapp

Команда запускает тесты и собирает данные о покрытии для выполненных файлов проекта. Чтобы просмотреть отчёт по этим данным, выполните следующую команду:

coverage report

Обратите внимание: во время запуска тестов выполнялся некоторый код Django, но здесь он не перечислен из-за флага source, переданного предыдущей команде.

Дополнительные параметры, например аннотированные HTML-отчёты со строками, которые не были выполнены, описаны в документации coverage.py.