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

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

class RequestFactory

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

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

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

Пример

Следующий пример демонстрирует юнит-тест с использованием фабрики запросов:

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)

AsyncRequestFactory

RequestFactory создает запросы по протоколу WSGI. Если вам нужно создать запросы по протоколу ASGI, включая правильный ASGI scope, вы можете использовать django.test.AsyncRequestFactory.

Этот класс напрямую совместим с API RequestFactory, с единственным отличием, заключающимся в том, что он возвращает экземпляры ASGIRequest, а не экземпляры WSGIRequest. Все его методы по-прежнему являются синхронными вызовами.

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

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

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

views.py

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(), перед продолжением кода вашего теста:

tests.py

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

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

Тестирование конфигураций мастер/раб

Если вы тестируете конфигурацию с несколькими базами данных с репликацией мастер/раб (в некоторых базах данных она называется первичная/вторичная), эта стратегия создания тестовых баз данных представляет собой проблему. При создании тестовых баз данных репликации не будет, и в результате данные, созданные на первичной базе данных, не будут видны на вторичной.

Для компенсации этого Django позволяет определить базу данных как тестовое зеркало. Рассмотрим следующий (упрощенный) пример конфигурации базы данных:

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
    }
}

В этой настройке у нас есть два сервера баз данных: dbprimary, описанный псевдонимом базы данных default, и dbreplica под псевдонимом replica. Как можно ожидать, dbreplica был настроен администратором базы данных как чтение реплики dbprimary, поэтому при нормальной работе любые записи в default будут появляться в replica.

Если Django создаст две независимые тестовые базы данных, это нарушит любые тесты, которые ожидают репликации. Однако база данных replica настроена как тестовое зеркало (с использованием настройки теста MIRROR), указывающей на то, что во время тестирования replica должна рассматриваться как зеркало default.

При конфигурировании тестовой среды тестовая версия replica не будет создана. Вместо этого подключение к replica будет перенаправлено на default. В результате записи в default будут появляться в replica — но поскольку это фактически та же база данных, а не из-за репликации данных между двумя базами данных.

Управление порядком создания тестовых баз данных

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

Если ваша конфигурация базы данных требует определенного порядка создания, вы можете указать зависимости, которые существуют, используя настройку теста DEPENDENCIES. Рассмотрим следующий (упрощенный) пример конфигурации базы данных:

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'],
        },
    }
}

В этой конфигурации база данных diamonds будет создана первой, так как это единственный псевдоним базы данных без зависимостей. Псевдонимы default и clubs будут созданы следующими (хотя порядок создания этой пары не гарантируется), затем hearts, и, наконец, spades.

Если в определении DEPENDENCIES имеются циклические зависимости, будет поднято исключение ImproperlyConfigured.

Дополнительные возможности `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

Давайте посмотрим внутрь нескольких файлов:

runtests.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. Вы можете добавить командно-строчные опции для управления объёмом вывода, передачи конкретных меток тестов для выполнения и т. д.

tests/test_settings.py

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. Это поведение включает:

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

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

Определение исполнителя тестов

Исполнитель тестов — это класс, определяющий метод run_tests(). Django поставляется с классом DiscoverRunner , который определяет стандартное поведение тестирования Django. Этот класс определяет точку входа run_tests() , а также ряд других методов, используемых run_tests() для подготовки, выполнения и завершения набора тестов.

class DiscoverRunner(pattern='test*.py', top_level=None, verbosity=1, interactive=True, failfast=False, keepdb=False, reverse=False, debug_mode=False, debug_sql=False, parallel=0, tags=None, exclude_tags=None, test_name_patterns=None, pdb=False, buffer=False, enable_faulthandler=True, timing=True, shuffle=False, logger=None, **kwargs)

DiscoverRunner будет искать тесты в любом файле, соответствующем pattern.

top_level можно использовать для указания каталога, содержащего ваши основные модули Python. Обычно Django может определить это автоматически, поэтому нет необходимости указывать этот параметр. При указании он обычно должен быть каталогом, содержащим ваш файл manage.py.

verbosity определяет количество сообщений и отладочной информации, которые будут выведены в консоль; 1 — это стандартный вывод, а 2 — подробный вывод.

Если interactive равно True, наборе тестов разрешено запрашивать у пользователя инструкции при выполнении набора тестов. Примером такого поведения может служить запрос разрешения на удаление существующей тестовой базы данных. Если interactive равно False, набор тестов должен быть в состоянии выполняться без ручного вмешательства.

Если failfast равно True, набор тестов будет остановлен после обнаружения первой неудачи теста.

Если keepdb равно True, набор тестов будет использовать существующую базу данных или создаст ее при необходимости. Если False, будет создана новая база данных, и пользователя попросят удалить существующую, если она есть.

Если reverse равно True, тесты будут выполняться в обратном порядке. Это может быть полезно для отладки тестов, которые не изолированы должным образом и имеют побочные эффекты. Группировка по тестовому классу сохраняется при использовании этого параметра. Этот параметр можно использовать совместно с --shuffle для изменения порядка для определенного случайного значения.

debug_mode задает значение настройки DEBUG перед запуском тестов.

parallel задает количество процессов. Если parallel больше 1, набор тестов будет выполняться в parallel процессах. Если количество тестовых случаев меньше, чем заданное количество процессов, Django соответственно уменьшит количество процессов. Каждый процесс получает свою собственную базу данных. Этот параметр требует пакета третьей стороны tblib для корректного отображения трассировок.

tags можно использовать для указания набора тегов для фильтрации тестов. Может комбинироваться с exclude_tags.

exclude_tags можно использовать для указания набора тегов для исключения тестов. Может комбинироваться с tags.

Если debug_sql равно True, неудачные тестовые случаи будут выводить SQL-запросы, записанные в журнал django.db.backends, а также трассировку.

Если verbosity равно 2, запросы во всех тестах будут выведены.

test_name_patterns можно использовать для указания набора шаблонов для фильтрации тестовых методов и классов по их именам.

Если pdb равно True, отладчик (pdb или ipdb) будет запущен при каждой ошибке или неудаче теста.

Если buffer равно True, результаты прошедших тестов будут отброшены.

Если enable_faulthandler равно True, faulthandler будет включен.

Если timing равно True, будут показаны временные метки тестов, включая настройку базы данных и общее время выполнения.

Если shuffle является целым числом, тестовые случаи будут перемешиваться в случайном порядке перед выполнением, используя целое число в качестве случайного значения. Если shuffle равно None, значение будет генерироваться случайным образом. В обоих случаях значение будет записано и установлено в self.shuffle_seed перед запуском тестов. Этот параметр может помочь выявить тесты, которые не изолированы должным образом. Группировка по тестовому классу сохраняется при использовании этого параметра.

logger можно использовать для передачи объекта Python журнал. Если он указан, журнал будет использоваться для регистрации сообщений вместо вывода в консоль. Объект журнала будет учитывать свой уровень ведения журнала, а не verbosity.

Время от времени Django может расширить возможности набора тестов, добавив новые параметры. Объявление **kwargs позволяет осуществить это расширение. Если вы создаете подкласс DiscoverRunner или создаете свой набор тестов, убедитесь, что он принимает **kwargs.

Ваш набор тестов может также определять дополнительные параметры командной строки. Создайте или переопределите метод класса add_arguments(cls, parser) и добавьте настраиваемые параметры, вызвав parser.add_argument() в методе, чтобы команда test могла использовать эти параметры.

Добавлено в Django 3.2:

Были добавлены параметры enable_faulthandler и timing.

Добавлено в Django 4.0:

Были добавлены параметры logger и shuffle.

Атрибуты

DiscoverRunner.test_suite: Класс, используемый для построения набора тестов. По умолчанию он установлен в unittest.TestSuite. Это можно переопределить, если вы хотите реализовать другую логику для сбора тестов.

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

DiscoverRunner.test_loader: Это класс, который загружает тесты, будь то из TestCases, модулей или иным образом, и объединяет их в наборы тестов для выполнения набором. По умолчанию он установлен в unittest.defaultTestLoader. Вы можете переопределить этот атрибут, если ваши тесты будут загружаться необычным способом.

Методы

DiscoverRunner.run_tests(test_labels, **kwargs)

Выполнить набор тестов.

test_labels позволяет указать, какие тесты нужно выполнить, и поддерживает несколько форматов (см. DiscoverRunner.build_suite() для списка поддерживаемых форматов).

Устарело начиная с версии 4.0: extra_tests — это список дополнительных экземпляров TestCase для добавления в набор, который выполняется набором тестов. Эти дополнительные тесты выполняются в дополнение к тем, которые обнаружены в модулях, перечисленных в test_labels.

Этот метод должен возвращать количество не пройденных тестов.

classmethod DiscoverRunner.add_arguments(parser): Переопределите этот метод класса, чтобы добавить настраиваемые аргументы, принимаемые командой управления test. См. argparse.ArgumentParser.add_argument() для получения подробностей о добавлении аргументов в анализатор.

DiscoverRunner.setup_test_environment(**kwargs): Настраивает тестовую среду, вызывая setup_test_environment() и устанавливая DEBUG в self.debug_mode (по умолчанию False).

DiscoverRunner.build_suite(test_labels=None, **kwargs)

Строит набор тестов, соответствующий предоставленным меткам тестов.

test_labels — это список строк, описывающих тесты, которые необходимо выполнить. Метка теста может иметь одну из четырех форм:

path.to.test_module.TestCase.test_method — Выполнить один тестовый метод в тестовом случае.
path.to.test_module.TestCase — Выполнить все тестовые методы в тестовом случае.
path.to.module — Поиск и выполнение всех тестов в указанном пакете или модуле Python.
path/to/directory — Поиск и выполнение всех тестов в указанном каталоге.

Если test_labels имеет значение None, набор тестов будет искать тесты во всех файлах в текущем каталоге, имена которых соответствуют его pattern (см. выше).

Возвращает экземпляр TestSuite готовый к запуску.

DiscoverRunner.setup_databases(**kwargs): Создает тестовые базы данных, вызывая setup_databases().

DiscoverRunner.run_checks(databases): Выполняет системные проверки для тестового databases.

DiscoverRunner.run_suite(suite, **kwargs)

Выполняет набор тестов.

Возвращает результат, полученный при выполнении набора тестов.

DiscoverRunner.get_test_runner_kwargs(): Возвращает ключевые аргументы для инициализации DiscoverRunner.test_runner.

DiscoverRunner.teardown_databases(old_config, **kwargs): Удаляет тестовые базы данных, восстанавливая условия до начала тестирования, вызывая teardown_databases().

DiscoverRunner.teardown_test_environment(**kwargs): Восстанавливает среду до состояния до начала тестирования.

DiscoverRunner.suite_result(suite, result, **kwargs): Вычисляет и возвращает код возврата на основе набора тестов и результата этого набора тестов.

DiscoverRunner.log(msg, level=None): Новое в Django 4.0.

Если установлен logger, записывает сообщение на указанном целочисленном уровне уровня ведения журнала (например, logging.DEBUG, logging.INFO, или logging.WARNING). В противном случае сообщение выводится в консоль, учитывая текущий verbosity. Например, сообщение не будет выведено, если verbosity равен 0, INFO и выше будут выведены, если verbosity равен как минимум 1, а DEBUG будет выведено, если он равен как минимум 2. level по умолчанию равен logging.INFO.

Утилиты тестирования

`django.test.utils`

Для помощи в создании собственного исполнителя тестов Django предоставляет ряд утилит в модуле django.test.utils.

setup_test_environment(debug=None)

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

Если debug не None, настройка DEBUG изменяется на её значение.

teardown_test_environment(): Выполняет глобальное завершение тестирования, например, удаляет средства мониторинга из системы шаблонов и восстанавливает нормальную работу с электронной почтой.

setup_databases(verbosity, interactive, *, time_keeper=None, keepdb=False, debug_sql=False, parallel=0, aliases=None, serialized_aliases=None, **kwargs)

Создаёт тестовые базы данных.

Возвращает структуру данных, содержащую достаточную информацию для отмены внесённых изменений. Эта структура будет передана функции teardown_databases() по завершении тестирования.

Аргумент aliases определяет, для каких псевдонимов DATABASES должны быть настроены тестовые базы данных. Если он не указан, используется по умолчанию все псевдонимы из DATABASES.

Аргумент serialized_aliases определяет подмножество aliases тестовых баз данных, состояние которых должно быть сериализовано для использования функции serialized_rollback. Если он не указан, используется значение по умолчанию aliases.

Изменено в Django 3.2:

Добавлен аргумент time_keeper, и все аргументы стали только ключевыми.

Изменено в Django 4.0:

Добавлен аргумент serialized_aliases.

teardown_databases(old_config, parallel=0, keepdb=False)

Удаляет тестовые базы данных, восстанавливая условия до начала тестирования.

old_config - это структура данных, определяющая изменения в конфигурации базы данных, которые необходимо отменить. Она является возвращаемым значением метода setup_databases().

`django.db.connection.creation`

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

create_test_db(verbosity=1, autoclobber=False, serialize=True, keepdb=False)

Создаёт новую тестовую базу данных и выполняет migrate в ней.

verbosity имеет такое же поведение, как и в run_tests().

autoclobber описывает поведение, которое произойдёт, если будет обнаружена база данных с таким же именем, как и тестовая база данных:

Если autoclobber равно False, пользователя попросят подтвердить удаление существующей базы данных. sys.exit вызывается, если пользователь не одобрит.
Если autoclobber равно True, база данных будет удалена без консультации с пользователем.

serialize определяет, будет ли Django сериализовать базу данных в строку JSON в оперативной памяти перед запуском тестов (используется для восстановления состояния базы данных между тестами, если у вас нет транзакций). Вы можете установить это в False для ускорения создания, если у вас нет ни одного класса тестов с serialized_rollback=True.

Если вы используете стандартный исполняемый файл тестов, вы можете контролировать это с помощью записи SERIALIZE в словаре TEST.

keepdb определяет, должен ли запуск тестов использовать существующую базу данных или создать новую. Если True, будет использоваться существующая база данных или создана, если её нет. Если False, будет создана новая база данных, и будет запрошена замена существующей, если она имеется.

Возвращает имя созданной тестовой базы данных.

create_test_db() имеет побочный эффект изменения значения NAME в DATABASES для соответствия имени тестовой базы данных.

destroy_test_db(old_database_name, verbosity=1, keepdb=False)

Удаляет базу данных, имя которой соответствует значению NAME в DATABASES, и устанавливает NAME в значение old_database_name.

Аргумент verbosity имеет такое же поведение, как и для DiscoverRunner.

Если аргумент keepdb равен True, то подключение к базе данных будет закрыто, но база данных не будет удалена.

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

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

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

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

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

coverage report

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

Для получения дополнительных опций, таких как аннотированные HTML-списки, показывающие пропущенные строки, см. документацию по coverage.py.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/4.0/topics/testing/advanced/