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

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

class RequestFactory

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

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

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

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

Добавлен параметр headers.

Пример

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

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

class AsyncRequestFactory

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

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

Произвольные ключевые аргументы в defaults добавляются непосредственно в область ASGI.

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

Добавлен параметр headers.

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

Для тестирования представлений на основе классов вне цикла запроса/ответа необходимо убедиться, что они настроены правильно, вызвав 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/",
            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.

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

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

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

Для компенсации 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, но поскольку это одна и та же база данных, а не потому, что происходит репликация данных между двумя базами данных. Поскольку это зависит от транзакций, тесты должны использовать TransactionTestCase вместо TestCase.

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

По умолчанию 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 — подробный вывод.

Если 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 могла использовать эти аргументы.

Атрибуты

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): Если 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.

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.2/topics/testing/advanced/