Темы расширенного тестирования ¶
Фабрика запросов ¶
-
класс
RequestFactory
¶
Класс RequestFactory
использует тот же API, что и тестовый клиент. Однако вместо того, чтобы вести себя как браузер, RequestFactory
предлагает способ создания экземпляра запроса, который может использоваться в качестве первого параметра любого представления. Это позволяет тестировать функцию просмотра так же, как вы тестируете любую другую функцию, например черный ящик, с известными данными в качестве входных данных и тестированием определенного результата.
API RequestFactory
немного более ограничен, чем у тестового клиента:
- Это дает доступ к методам HTTP только
get()
,post()
,put()
,delete()
,head()
,options()
иtrace()
. - Все эти методы принимают одни и те же параметры, за исключением из
follow
. Поскольку это только фабрика, производящая запросы, вы несете ответственность за ответ. - Он не поддерживает промежуточное ПО. Атрибуты сеанса и аутентификации должны быть предоставлены самим тестом, если необходимо, для правильной работы представления.
Пример ¶
Следующий пример представляет собой модульный тест с использованием фабрики запросов:
from django.contrib.auth.models import AnonymousUser, User
from django.test import RequestFactory, TestCase
from .views import MyView, my_view
class SimpleTest(TestCase):
def setUp(self):
# Every test needs access to the request factory.
self.factory = RequestFactory()
self.user = User.objects.create_user(
username='jacob', email='[email protected]…', password='top_secret')
def test_details(self):
# Create an instance of a GET request.
request = self.factory.get('/customer/details')
# Recall that middleware are not supported. You can simulate a
# logged-in user by setting request.user manually.
request.user = self.user
# Or you can simulate an anonymous user by setting request.user to
# an AnonymousUser instance.
request.user = AnonymousUser()
# Test my_view() as if it were deployed at /customer/details
response = my_view(request)
# Use this syntax for class-based views.
response = MyView.as_view()(request)
self.assertEqual(response.status_code, 200)
AsyncRequestFactory ¶
RequestFactory
создает запросы, подобные WSGI. Если вы хотите создавать запросы, подобные ASGI, в том числе иметь правильный ASGI scope
, вы можете вместо этого использовать
django.test.AsyncRequestFactory
.
Этот класс напрямую совместим с API RequestFactory
, с той лишь разницей, что он возвращает ASGIRequest
экземпляры, а не
WSGIRequest
экземпляры. Все его методы по-прежнему являются синхронными вызываемыми.
Тестирование представлений на основе классов ¶
Чтобы протестировать представления на основе классов вне цикла запроса / ответа, вы должны убедиться, что они настроены правильно, вызывая их setup()
после их создания.
Например, начиная со следующего вида класса:
from django.views.generic import TemplateView
class HomeView(TemplateView):
template_name = 'myapp/home.html'
def get_context_data(self, **kwargs):
kwargs['environment'] = 'Production'
return super().get_context_data(**kwargs)
Вы можете напрямую протестировать метод get_context_data()
, сначала создав экземпляр представления, затем передав запрос, setup()
прежде чем приступить к тестированию кода:
from django.test import RequestFactory, TestCase
from .views import HomeView
class HomePageTest(TestCase):
def test_environment_set_in_context(self):
request = RequestFactory().get('/')
view = HomeView()
view.setup(request)
context = view.get_context_data()
self.assertIn('environment', context)
Тесты с несколькими именами хостов ¶
Настройка ALLOWED_HOSTS
проверяется во время выполнения тестов. Это позволяет тестирующему клиенту различать внутренние и внешние URL-адреса.
Проекты, которые управляют несколькими доменами на сайте или адаптируют свое поведение в зависимости от хоста запроса и которые используют определенные имена хостов при тестировании, должны включать эти имена хостов в ALLOWED_HOSTS
.
Первый вариант для этого - добавить хосты в файл настроек. Например, набор тестов docs.djangoproject.com содержит следующее:
from django.test import TestCase
class SearchFormTestCase(TestCase):
def test_empty_get(self):
response = self.client.get('/en/dev/search/', HTTP_HOST='docs.djangoproject.dev:8000')
self.assertEqual(response.status_code, 200)
а файл настроек содержит список областей, поддерживаемых проектом:
ALLOWED_HOSTS = [
'www.djangoproject.dev',
'docs.djangoproject.dev',
...
]
Другой вариант - добавить необходимые хосты ALLOWED_HOSTS
с помощью override_settings()
или modify_settings()
. Этот вариант может быть предпочтительным для автономных приложений, которые не могут предоставить свой собственный файл настроек, или для проектов, список доменов которых не фиксирован (например, поддомены в общей службе). Например, можно было бы написать такой тест для домена http://otherserver/
:
from django.test import TestCase, override_settings
class MultiDomainTestCase(TestCase):
@override_settings(ALLOWED_HOSTS=['otherserver'])
def test_other_domain(self):
response = self.client.get('http://otherserver/foo/bar/')
Отключение проверки ALLOWED_HOSTS
( ) во время выполнения тестов предотвращает создание тестовым клиентом информативного сообщения об ошибке, если для внешнего URL-адреса вызывается перенаправление.ALLOWED_HOSTS = ['*']
Тесты с несколькими базами данных ¶
Тестирование конфигурации первичной / реплики ¶
Если вы тестируете конфигурацию с несколькими базами данных, включающими первичную / репликацию (называемую в некоторых базах данных как главный / подчиненный), эта стратегия создания тестовых баз данных является проблематичной. При создании тестовых баз данных репликация не выполняется, и поэтому данные, созданные в первичной базе данных, не будут видны на репликах.
Чтобы обойти эту проблему, 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
и поэтому всегда сначала создает базу данных . Однако для любой другой базы данных в вашей тестовой настройке нет никакой гарантии относительно порядка, в котором базы данных создаются.
Если для конфигурации вашей базы данных требуется четко определенный порядок создания, вы можете указать зависимости между базами данных в настройках теста 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.
Распространенной практикой является размещение каталога тестов рядом с кодом приложения со следующей структурой:
runtests.py
polls/
__init__.py
models.py
...
tests/
__init__.py
models.py
test_settings.py
tests.py
Давайте посмотрим, что находится в некоторых из этих файлов:
#!/usr/bin/env python
import os
import sys
import django
from django.conf import settings
from django.test.utils import get_runner
if __name__ == "__main__":
os.environ['DJANGO_SETTINGS_MODULE'] = 'tests.test_settings'
django.setup()
TestRunner = get_runner(settings)
test_runner = TestRunner()
failures = test_runner.run_tests(["tests"])
sys.exit(bool(failures))
Это сценарий, вызываемый для запуска набора тестов. Он настраивает среду Django, создает тестовую базу данных и запускает тесты.
Для ясности этот пример содержит только минимум, необходимый для использования средства запуска тестов Django. Однако можно представить добавление параметров командной строки для контроля подробности, передачи определенных тестовых меток для запуска и т. Д.
SECRET_KEY = 'fake-key'
INSTALLED_APPS = [
"tests",
]
Этот файл содержит необходимые настройки Django для запуска тестов вашего приложения.
Опять же, это минимальный пример; Для работы тестов могут потребоваться дополнительные настройки.
Поскольку пакет тестов включен INSTALLED_APPS
при запуске тестов, можно определять модели только для тестов в файле models.py
.
Использование других тестовых инфраструктур ¶
Ясно, что это unittest
не единственная инфраструктура тестирования Python. Хотя Django не предоставляет явной поддержки для других систем тестирования, он предоставляет способ вызывать тесты, созданные для другой системы, как если бы они были обычными тестами Django.
При запуске Django проверяет настройку, чтобы определить, что делать. По умолчанию содержит . Этот класс определяет поведение тестирования Django по умолчанию. Это поведение включает:./manage.py test
TEST_RUNNER
TEST_RUNNER
'django.test.runner.DiscoverRunner'
- Общая подготовка перед экзаменами.
- Найдите тесты в любом файле ниже текущего каталога, имя которого соответствует шаблону
test*.py
. - Создание тестовых баз данных.
- Запуск
migrate
для установки моделей и исходных данных в тестовые базы данных. - Проведение системных проверок .
- Запуск обнаруженных тестов.
- Удаление тестовых баз.
- Общая доработка после тестов.
Если вы определите свой собственный класс запуска тестов и укажете этот класс в TEST_RUNNER
, Django будет использовать вашу программу запуска тестов при каждом вызове . Таким образом, можно использовать любую тестовую систему, которую можно запустить из кода Python, или изменить процесс выполнения тестов Django, чтобы адаптировать тесты к любым конкретным потребностям../manage.py test
Определение исполнителя тестов ¶
Средство выполнения тестов - это класс, определяющий метод 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 , test_name_patterns = None , pdb = False , buffer = False , ** kwargs ) ¶ DiscoverRunner
ищет тесты в любом файле, соответствующем шаблонуpattern
.top_level
может использоваться для указания каталога, содержащего модули Python верхнего уровня. Django обычно может обнаружить это автоматически, поэтому эта опция не является абсолютно необходимой. Когда он установлен, он обычно должен соответствовать каталогу, содержащему файлmanage.py
.verbosity
определяет количество уведомлений и отладочной информации, которые будут отображаться на консоли;0
ничего не отображает,1
соответствует нормальному отображению и2
подробному отображению.Если
interactive
естьTrue
, то набор тестов имеет право задавать вопросы пользователю во время выполнения. Например, она может запросить разрешение на удаление существующей тестовой базы данных. Еслиinteractive
естьFalse
, набор тестов должен быть в состоянии работать без какого - либо ручного вмешательства пользователя.Если
failfast
равноTrue
, набор тестов останавливается сразу после первого сбоя теста.Если
keepdb
естьTrue
, тестовый набор будет использовать существующую базу данных или создать новую , если это необходимо. Если значение равноFalse
, всегда создается новая база данных с просьбой удалить любую существующую базу данных с тем же именем.Если
reverse
стоитTrue
, тестовые примеры выполняются в обратном порядке. Это может быть полезно для отладки тестов, которые неправильно изолированы и вызывают побочные эффекты. При использовании этой опции сохраняется группировка по тестовым классам .debug_mode
указывает значение, которое должна принять настройкаDEBUG
перед запуском тестов.Если
debug_sql
применимоTrue
, тесты не пройдены, отображают SQL-запросы, записанные в django.db.backends, в дополнение к стеку вызовов. Еслиverbosity
равно2
, отображаются запросы для всех тестов.test_name_patterns
может использоваться для определения набора шаблонов для фильтрации методов и классов тестирования по имени.Если
pdb
естьTrue
, отладчик (pdb
илиipdb
) будет запускаться для каждой ошибки или сбоя теста.Если
buffer
естьTrue
, результаты прохождения тестов будут отброшены.Время от времени Django может расширять возможности средства запуска тестов, добавляя новые параметры. Объявление
**kwargs
допускает это расширение. Если вы унаследовали отDiscoverRunner
собственного средства выполнения тестов или написали его, убедитесь, что он принимает**kwargs
.Ваш тестовый исполнитель также может установить дополнительные параметры командной строки. Создайте или переопределите метод класса и добавьте настраиваемые параметры, вызвав этот метод, чтобы команда могла использовать эти параметры.
add_arguments(cls, parser)
parser.add_argument()
test
Новое в Django 3.0:Параметр
pdb
добавлен.Новое в Django 3.1:buffer
Аргумент был добавлен.
Атрибуты ¶
-
DiscoverRunner.
test_suite
¶ Класс, используемый для создания набора тестов. По умолчанию это
unittest.TestSuite
. Это значение можно переопределить, если вы хотите реализовать другую логику для сбора тестов.
-
DiscoverRunner.
test_runner
¶ Этот класс - средство выполнения тестов низкого уровня, используемое для запуска отдельных тестов и форматирования результатов. По умолчанию это
unittest.TextTestRunner
. Несмотря на досадное сходство соглашений об именах, это не тот тип классаDiscoverRunner
, который поддерживает более широкий спектр обязанностей. Вы можете переопределить этот атрибут, чтобы изменить способ запуска тестов и отображения их результатов.
-
DiscoverRunner.
test_loader
¶ Это класс, который загружает тесты из классов
TestCase
, модулей или другими способами и объединяет их в наборы тестов, которые может запускать средство запуска. По умолчаниюunittest.defaultTestLoader
. Вы можете переопределить этот атрибут, если ваши тесты нужно загружать необычным образом.
Методы ¶
-
DiscoverRunner.
run_tests
( test_labels , extra_tests = None , ** kwargs ) ¶ Запускает набор тестов.
test_labels
позволяет указать тесты для запуска и принимает несколько форматов (см.DiscoverRunner.build_suite()
список поддерживаемых форматов).extra_tests
- это списокTestCase
дополнительных экземпляров, которые нужно добавить в набор, запускаемый исполнителем тестов. Эти дополнительные тесты выполняются в дополнение к тестам, обнаруженным в модулях, перечисленных вtest_labels
.Этот метод должен возвращать количество неудачных тестов.
-
classmethod
DiscoverRunner.
add_arguments
( парсер ) ¶ Переопределите этот метод класса, чтобы добавить настраиваемые параметры, принимаемые командой администрирования
test
. См.argparse.ArgumentParser.add_argument()
Дополнительные сведения о добавлении параметров командной строки.
-
DiscoverRunner.
setup_test_environment
( ** kwargs ) ¶ setup_test_environment()
Настраивает тестовую среду, вызывая и задаваяDEBUG
значениеself.debug_mode
(поFalse
умолчанию).
-
DiscoverRunner.
build_suite
( test_labels , extra_tests = None , ** kwargs ) ¶ Создает набор тестов, соответствующий заданным именам тестов.
test_labels
это список строк, описывающих тесты, которые нужно запустить. Название теста может иметь четыре формы:chemin.vers.module_test.TestCase.methode_test
- Запускает единственный тестовый метод в тестовом примере.chemin.vers.module_test.TestCase
- Запускает все методы тестирования тестового примера.chemin.vers.module
- Находит и запускает все тесты для данного пакета или модуля Python.chemin/vers/répertoire
- Находит и запускает все тесты в поддереве данного каталога.
Если
test_labels
содержит значениеNone
, средство запуска тестов ищет тесты во всех файлах ниже текущего каталога, имя которых соответствует его шаблонуpattern
(см. Выше).extra_tests
- это списокTestCase
дополнительных экземпляров, которые нужно добавить в набор, запускаемый исполнителем тестов. Эти дополнительные тесты выполняются в дополнение к тестам, обнаруженным в модулях, перечисленных вtest_labels
.Возвращает экземпляр,
TestSuite
готовый к выполнению.
-
DiscoverRunner.
setup_databases
( ** kwargs ) ¶ Создает тестовые базы данных путем вызова
setup_databases()
.
-
DiscoverRunner.
run_checks
( базы данных ) ¶ Запускает системные проверки по тесту
databases
.Новое в Django 3.1:databases
Параметр был добавлен.
-
DiscoverRunner.
run_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
( сюита , результат , ** kwargs ) ¶ Вычисляет и возвращает код возврата на основе набора тестов и результатов этих тестов.
Тестовые утилиты ¶
django.test.utils
¶
Для создания собственного средства выполнения тестов Django предоставляет в модуле ряд служебных методов django.test.utils
.
-
setup_test_environment
( отладка = Нет ) ¶ Выполняет общую настройку перед тестированием, такую как установка адаптаций системы рендеринга шаблонов и настройка фиктивного почтового ящика.
Если
debug
нетNone
, то настройкаDEBUG
обновляется с этим значением.
-
teardown_test_environment
() ¶ Выполняет общую доработку после тестирования, такую как удаление системных адаптаций из шаблонов и восстановление служб обмена сообщениями по умолчанию.
-
setup_databases
( многословие , интерактивность , keepdb = False , debug_sql = False , parallel = 0 , aliases = None , ** kwargs ) ¶ Создает тестовые базы данных.
Возвращает структуру данных, содержащую достаточно подробностей, чтобы отменить любые сделанные изменения. Затем эти данные передаются в функцию
teardown_databases()
во время завершения тестов.Параметр
aliases
определяет, для каких псевдонимовDATABASES
тестовых баз данных нужно подготовить. Если отсутствует, по умолчанию он содержит все псевдонимыDATABASES
.
-
teardown_databases
( old_config , parallel = 0 , keepdb = False ) ¶ Удаляет тестовые базы данных, восстанавливая дотестовую ситуацию.
old_config
- это структура данных, определяющая, какие изменения конфигурации базы данных следует откатить. Это возвращаемое значение методаsetup_databases()
.
django.db.connection.creation
¶
Модуль создания ядра базы данных также предлагает некоторые утилиты, которые могут быть полезны во время тестирования.
-
create_test_db
( многословность = 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
inDATABASES
обновляется, чтобы соответствовать имени тестовой базы данных.- Если
-
destroy_test_db
( Old_database_name , подробность = 1 , keepdb = False ) ¶ Удаляет базу данных, имя которой совпадает со значением
NAME
In,DATABASES
и обновляетNAME
значение вold_database_name
.Параметр
verbosity
имеет тот же эффект, что и дляDiscoverRunner
.Если параметр
keepdb
установленTrue
, соединение с базой данных будет закрыто, но база данных не будет уничтожена.
Интеграция с coverage.py
¶
Покрытие кода представляет собой количество исходного кода, проверяемого тестами. Он показывает, какие части кода проходят тестирование, а какие нет. Это важный аспект тестирования приложений, поэтому настоятельно рекомендуется контролировать охват тестированием.
Django можно легко интегрировать с покрытием .py , инструментом для измерения покрытия кода программ Python. Сначала установите extension.py . Затем запустите следующую команду из каталога вашего проекта, содержащего manage.py
:
coverage run --source='.' manage.py test myapp
Это запустит тесты и соберет данные о покрытии из файлов, запущенных в вашем проекте. Вы можете просмотреть отчет с этими данными, введя следующую команду:
coverage report
Обратите внимание, что код Django был выполнен во время выполнения тестов, но он не отображается в отчете из-за параметра, source
указанного в предыдущей команде.
Дополнительные параметры, такие как аннотированные HTML-списки с подробным описанием отсутствующих строк, см. В документации по охвату .