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

Завод по запросу ¶

класс 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='[email protected]…', 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/', HTTP_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_HOSTScheck ( ) при запуске тестов предотвращает появление полезного сообщения об ошибке тестовым клиентом, если вы выполняете перенаправление на внешний URL-адрес.ALLOWED_HOSTS = ['*']

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

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после очистки базы данных не генерируется, его состояние после a TransactionTestCaseне такое же, как после a TestCase: отсутствуют строки, созданные слушателями post_migrate. Учитывая порядок, в котором выполняются тесты , это не проблема, при условии, что либо все TransactionTestCaseв данном наборе тестов объявлены available_apps, либо ни один из них.

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

TransactionTestCase.reset_sequences¶

Установка на будет убедиться , что последовательности всегда сбрасываются перед испытанием:reset_sequences = TrueTransactionTestCase

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.

Распространенной практикой является каталог тестов рядом с кодом приложения со следующей структурой:

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, необходимые для запуска тестов вашего приложения.

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

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

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

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

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

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

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

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

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

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

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

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

coverage report

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

Дополнительные параметры, такие как аннотированные списки HTML с подробными сведениями о пропущенных строках, см. В документации покрытия .py.