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

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

class RequestFactory [source]

Класс 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 или же ни один из них этого не делает.

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

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.