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

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

class RequestFactory

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

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

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

Пример

Следующий пример демонстрирует использование request factory в тесте:

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 определяет количество уведомлений и отладочной информации, которые будут выводиться в консоль; 0 — это отсутствие вывода, 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, seed будет сгенерирован случайным образом. В обоих случаях seed будет записан и установлен на self.shuffle_seed перед запуском тестов. Этот параметр может помочь выявить тесты, которые не изолированы должным образом. Группировка по тестовому классу сохраняется при использовании этого параметра.

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

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

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

Новое в 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.

END_OF_DOCUMENT_MARKER

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