Темы расширенного тестирования ¶
Завод по запросу ¶
-
класс
RequestFactory
¶
Он RequestFactory
использует тот же API, что и тестовый клиент. Однако вместо того, чтобы вести себя как браузер, RequestFactory предоставляет способ создания экземпляра запроса, который можно использовать в качестве первого аргумента для любого представления. Это означает, что вы можете протестировать функцию просмотра так же, как и любую другую функцию - в виде черного ящика с точно известными входами, тестирование определенных выходов.
API для RequestFactory
- это немного ограниченное подмножество тестового клиентского API:
- Он имеет доступ только к методам 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()
метод, сначала создав экземпляр представления, а затем передав request
в 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
check ( ) при запуске тестов предотвращает появление полезного сообщения об ошибке тестовым клиентом, если вы выполняете перенаправление на внешний 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
базы данных, и поэтому всегда 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
после очистки базы данных не генерируется, его состояние после aTransactionTestCase
не такое же, как после aTestCase
: отсутствуют строки, созданные слушателями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 , parallel = 0 , tags = None , exclude_tags = None , test_name_patterns = None , pdb = False , buffer = False , enable_faulthandler = True , Timing = True , ** 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
параметр должен быть установлен перед запуском тестов.parallel
указывает количество процессов. Еслиparallel
больше чем1
, набор тестов будет запускаться вparallel
процессах. Если количество тестов меньше, чем настроенных процессов, Django соответственно уменьшит количество процессов. Каждый процесс получает свою базу данных. Этот параметр требует, чтобы стороннийtblib
пакет правильно отображал трассировку.tags
может использоваться для указания набора тегов для тестов фильтрации . Можно комбинировать сexclude_tags
.exclude_tags
может использоваться для указания набора тегов для исключения тестов . Можно комбинировать сtags
.Если
debug_sql
естьTrue
, в противном случае тестовых случаев будут выводить SQL запросы регистрируются в django.db.backends Logger , а также отладочные сообщения . Еслиverbosity
есть2
, то выводятся запросы во всех тестах.test_name_patterns
может использоваться для указания набора шаблонов для фильтрации тестовых методов и классов по их именам.Если
pdb
естьTrue
, отладчик (pdb
илиipdb
) будет запускаться при каждой ошибке или сбое теста.Если
buffer
естьTrue
, результаты прохождения тестов будут отброшены.Если
enable_faulthandler
естьTrue
,faulthandler
будет включен.Если
timing
естьTrue
, тест тайминги, в том числе настройки базы данных и общее время выполнения, будут показаны.Время от времени Django может расширять возможности средства запуска тестов, добавляя новые аргументы.
**kwargs
Декларация позволяет для этого расширения. Если вы создаете подклассDiscoverRunner
или пишете свой собственный тестовый исполнитель, убедитесь, что он принимает**kwargs
.Ваш тестовый исполнитель также может определять дополнительные параметры командной строки. Создайте или переопределите метод класса и добавьте настраиваемые аргументы путем вызова внутри метода, чтобы команда могла использовать эти аргументы.
add_arguments(cls, parser)
parser.add_argument()
test
Новое в Django 3.1:buffer
Аргумент был добавлен.Новое в Django 3.2:enable_faulthandler
Иtiming
были добавлены аргументы.
Атрибуты ¶
-
DiscoverRunner.
test_suite
¶ Класс, используемый для создания набора тестов. По умолчанию установлено значение
unittest.TestSuite
. Это можно изменить, если вы хотите реализовать другую логику для сбора тестов.
-
DiscoverRunner.
test_runner
¶ Это класс низкоуровневого средства выполнения тестов, который используется для выполнения отдельных тестов и форматирования результатов. По умолчанию установлено значение
unittest.TextTestRunner
. Несмотря на досадное сходство в соглашениях об именах, это не тот тип классаDiscoverRunner
, который охватывает более широкий набор обязанностей. Вы можете переопределить этот атрибут, чтобы изменить способ запуска тестов и составления отчетов.
-
DiscoverRunner.
test_loader
¶ Это класс, который загружает тесты, будь то из TestCases, модулей или иным образом, и объединяет их в наборы тестов для выполнения бегуном. По умолчанию установлено значение
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 = Нет , ** 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
(см. Выше).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
( подробность , интерактивность , * , time_keeper = None , keepdb = False , debug_sql = False , parallel = 0 , aliases = None , ** kwargs ) ¶ Создает тестовые базы данных.
Возвращает структуру данных, которая предоставляет достаточно подробностей для отмены внесенных изменений. Эти данные будут предоставлены
teardown_databases()
функции по завершении тестирования.В
aliases
аргументе определяет , какиеDATABASES
псевдонимы тестовых баз данных должны быть настроены для. Если он не указан, по умолчанию используются всеDATABASES
псевдонимы.Изменено в Django 3.2:time_keeper
Kwarg был добавлен, и все kwargs были сделаны только с ключевыми словами.
-
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 , verbosity = 1 , keepdb = False ) ¶ Уничтожает базу данных, имя которой является значением
NAME
inDATABASES
, и устанавливает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 с подробными сведениями о пропущенных строках, см. В документации покрытия .py.