Расширенные темы тестирования¶

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

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. Учитывая order in which tests are executed, это не является проблемой, если либо все 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 для тестирования многократно используемых приложений¶

Если вы пишете reusable application, вы, возможно, захотите использовать Django test runner, чтобы запустить свой собственный набор тестов и таким образом воспользоваться инфраструктурой тестирования 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 settings, необходимые для запуска тестов вашего приложения.

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

Поскольку пакет 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. Выполнение system checks.
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.