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

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(), сначала создав экземпляр представления, затем передав запрос в 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. Учитывая порядок выполнения тестов <order-of-tests>`, это не проблема, при условии, что либо все 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. Запуск миграции для установки моделей и исходных данных в тестовые базы данных.

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.