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

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

class RequestFactory [source]

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

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

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

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

Параметр query_params был добавлен.

Пример

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

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 [source]

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

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

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

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

Параметр query_params был добавлен.

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

Для тестирования представлений на основе классов вне цикла запрос/ответ необходимо убедиться, что они настроены корректно, вызвав 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, durations=None, **kwargs) [source]

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 будут выводиться в verbosity в дополнение к отладочной информации. Если 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.

durations отобразит список N самых медленных тестовых случаев. Установка этого значения в 0 приведет к отображению продолжительности выполнения всех тестов. Требуется Python 3.12+.

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

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

Новое в Django 5.0:

Аргумент durations был добавлен.

Атрибуты

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

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

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

Методы

DiscoverRunner.run_tests(test_labels, **kwargs) [source]

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

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

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

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

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

DiscoverRunner.build_suite(test_labels=None, **kwargs) [source]

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

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) [source]: Создаёт тестовые базы данных, вызывая setup_databases().

DiscoverRunner.run_checks(databases) [source]: Выполняет проверки системы на тестовом databases.

END_OF_DOCUMENT_MARKER

DiscoverRunner.run_suite(suite, **kwargs) [source]

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

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

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

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

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

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

DiscoverRunner.log(msg, level=None) [source]: Если 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) [source]

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

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

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

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

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

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

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

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

teardown_databases(old_config, parallel=0, keepdb=False) [source]

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

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.

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. Далее, выполните следующую команду из папки вашего проекта, содержащей 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/5.1/topics/testing/advanced/