unittest — Фреймворк для модульного тестирования

Параметры командной строки

unittest поддерживает следующие параметры командной строки:

-b, --buffer

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

-c, --catch

Ctrl-C во время выполнения теста ожидает завершения текущего теста, а затем сообщает все результаты до этого момента. Второй Ctrl-C вызывает обычное исключение KeyboardInterrupt.

См. Обработка сигналов для функций, предоставляющих эту функциональность.

-f, --failfast

Остановка выполнения теста при первой ошибке или сбое.

-k

Запускаются только те тестовые методы и классы, которые соответствуют шаблону или подстроке. Этот параметр можно использовать несколько раз, в этом случае включаются все тестовые случаи, которые соответствуют любому из заданных шаблонов.

Шаблоны, содержащие символ подстановки (*), сопоставляются с именем теста с помощью fnmatch.fnmatchcase(); в противном случае используется простое сопоставление подстроки, чувствительной к регистру.

Шаблоны сопоставляются с полным квалифицированным именем тестового метода, импортированным загрузчиком тестов.

Например, -k foo соответствует foo_tests.SomeTest.test_something, bar_tests.SomeTest.test_foo, но не bar_tests.FooTest.test_something.

--locals

Отображение локальных переменных в отслеживающих отладочных выводах.

--durations N

Отображение N самых медленных тестовых случаев (N=0 для всех).

Командная строка также может использоваться для обнаружения тестов, для запуска всех тестов в проекте или только подмножества.

Тестовые случаи

class unittest.TestCase(methodName='runTest')

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

Каждый экземпляр TestCase выполнит один базовый метод: метод с именем methodName. В большинстве случаев использования TestCase, вы не будете изменять methodName или переопределять метод по умолчанию runTest().

Изменено в версии 3.2: TestCase может быть успешно создан без указания methodName. Это упрощает эксперименты с TestCase из интерактивного интерпретатора.

Экземпляры TestCase предоставляют три группы методов: одна группа для запуска теста, другая для проверки условий и отчёта о сбоях реализацией теста, и некоторые методы запроса, позволяющие собрать информацию о самом тесте.

Методы первой группы (запуск теста) являются:

setUp()

Метод, вызываемый для подготовки тестового окружения. Он вызывается непосредственно перед вызовом тестового метода; любое исключение, кроме AssertionError или SkipTest, поднятое этим методом, будет рассматриваться как ошибка, а не как сбой теста. По умолчанию ничего не делает.

tearDown()

Метод, вызываемый сразу после вызова тестового метода и записи результата. Он вызывается даже если тестовый метод поднял исключение, поэтому реализация в производных классах может потребовать особой осторожности при проверке внутреннего состояния. Любое исключение, кроме AssertionError или SkipTest, поднятое этим методом, будет рассматриваться как дополнительная ошибка, а не как сбой теста (тем самым увеличивая общее количество сообщённых ошибок). Этот метод будет вызван только в случае успешного завершения setUp(), независимо от результата тестового метода. По умолчанию ничего не делает.

setUpClass()

Метод класса, вызываемый перед запуском тестов в отдельном классе. setUpClass вызывается с классом в качестве единственного аргумента и должен быть помечен как classmethod():

@classmethod
def setUpClass(cls):
    ...

См. Фикстуры класса и модуля для получения дополнительных сведений.

Добавлен в версии 3.2.

tearDownClass()

Метод класса, вызываемый после запуска тестов в отдельном классе. tearDownClass вызывается с классом в качестве единственного аргумента и должен быть помечен как classmethod():

@classmethod
def tearDownClass(cls):
    ...

См. Фикстуры класса и модуля для получения дополнительных сведений.

Добавлен в версии 3.2.

run(result=None)

Запустить тест, собрав результат в объект TestResult, переданный в качестве result. Если result пропущен или None, создаётся временный объект результата (вызовом метода defaultTestResult()) и используется. Объект результата возвращается вызывающей стороне метода run().

То же самое можно сделать, просто вызвав экземпляр TestCase.

Изменено в версии 3.3: Предыдущие версии run не возвращали результат. То же самое не происходило и при вызове экземпляра.

skipTest(reason)

Вызов этого во время тестового метода или setUp() пропускает текущий тест. См. Пропуск тестов и ожидаемые ошибки для получения дополнительной информации.

Добавлен в версии 3.1.

subTest(msg=None, **params)

Возвращает менеджер контекста, который выполняет заключённый блок кода в качестве подтеста. msg и params — необязательные произвольные значения, которые отображаются всякий раз, когда подтест терпит неудачу, позволяя чётко их идентифицировать.

Тестовый случай может содержать любое количество объявлений подтестов, и они могут быть произвольно вложены.

См. Различение итераций тестов с помощью подтестов для получения дополнительной информации.

Добавлен в версии 3.4.

debug()

Запустить тест без сбора результатов. Это позволяет исключениям, поднятым тестом, передаваться вызывающей стороне и может использоваться для поддержки запуска тестов под отладчиком.

Класс TestCase предоставляет несколько методов assert для проверки и отчёта о сбоях. В следующей таблице перечислены наиболее часто используемые методы (см. таблицы ниже для получения более подробной информации о методах assert):

Метод	Проверяет, что	Новое в
assertEqual(a, b)	a == b
assertNotEqual(a, b)	a != b
assertTrue(x)	bool(x) is True
assertFalse(x)	bool(x) is False
assertIs(a, b)	a is b	3.1
assertIsNot(a, b)	a is not b	3.1
assertIsNone(x)	x is None	3.1
assertIsNotNone(x)	x is not None	3.1
assertIn(a, b)	a in b	3.1
assertNotIn(a, b)	a not in b	3.1
assertIsInstance(a, b)	isinstance(a, b)	3.2
assertNotIsInstance(a, b)	not isinstance(a, b)	3.2

Все методы assert принимают аргумент msg, который, если указан, используется в качестве сообщения об ошибке при сбое (см. также longMessage). Обратите внимание, что аргумент msg в ключевых словах может быть передан в assertRaises(), assertRaisesRegex(), assertWarns(), assertWarnsRegex() только в том случае, если они используются как менеджеры контекста.

assertEqual(first, second, msg=None)

Проверка, что first и second равны. Если значения не сравниваются как равные, тест завершится сбоем.

Кроме того, если first и second являются точно одного типа и одним из списком, кортежом, словарем, набором, неизменяемым набором или строкой, или любым типом, который подкласс регистрирует с помощью addTypeEqualityFunc(), вызывается функция сравнения, специфичная для типа, чтобы сгенерировать более полезное сообщение об ошибке по умолчанию (см. также список методов, специфичных для типа).

Изменено в версии 3.1: Добавлена автоматическая вызов функции сравнения, специфичной для типа.

Изменено в версии 3.2: assertMultiLineEqual() добавлена в качестве функции сравнения типов по умолчанию для сравнения строк.

assertNotEqual(first, second, msg=None)

Проверка, что first и second не равны. Если значения сравниваются как равные, тест завершится сбоем.

assertTrue(expr, msg=None)

assertFalse(expr, msg=None)

Проверка, что expr истинно (или ложно).

Обратите внимание, что это эквивалентно bool(expr) is True и не эквивалентно expr is True (используйте assertIs(expr, True) для последнего). Этот метод также следует избегать, когда доступны более специфичные методы (например, assertEqual(a, b) вместо assertTrue(a == b)), потому что они предоставляют более подробное сообщение об ошибке в случае сбоя.

assertIs(first, second, msg=None)

assertIsNot(first, second, msg=None)

Проверка, что first и second являются (или не являются) одним и тем же объектом.

Добавлен в версии 3.1.

assertIsNone(expr, msg=None)

assertIsNotNone(expr, msg=None)

Проверка, что expr является (или не является) None.

Добавлен в версии 3.1.

assertIn(member, container, msg=None)

assertNotIn(member, container, msg=None)

Проверка, что member находится (или не находится) в container.

Добавлен в версии 3.1.

assertIsInstance(obj, cls, msg=None)

assertNotIsInstance(obj, cls, msg=None)

Проверка, что obj является (или не является) экземпляром cls (который может быть классом или кортежем классов, как поддерживается isinstance()). Для проверки точного типа используйте assertIs(type(obj), cls).

Добавлен в версии 3.2.

Также возможно проверить возникновение исключений, предупреждений и сообщений журнала с помощью следующих методов:

Метод	Проверяет, что	Новый в
assertRaises(exc, fun, *args, **kwds)	fun(*args, **kwds) вызывает exc
assertRaisesRegex(exc, r, fun, *args, **kwds)	fun(*args, **kwds) вызывает exc, и сообщение соответствует регулярному выражению r	3.1
assertWarns(warn, fun, *args, **kwds)	fun(*args, **kwds) вызывает warn	3.2
assertWarnsRegex(warn, r, fun, *args, **kwds)	fun(*args, **kwds) вызывает warn, и сообщение соответствует регулярному выражению r	3.2
assertLogs(logger, level)	Блок with записывает в журнал logger с минимальным уровнем level	3.4
assertNoLogs(logger, level)	The with block does not log on logger с минимальным уровнем level	3.10

assertRaises(exception, callable, *args, **kwds)

assertRaises(exception, *, msg=None)

Проверка, что исключение возникает, когда callable вызывается с любыми позиционными или ключевыми аргументами, которые также передаются в assertRaises(). Тест проходит, если exception возникает, это ошибка, если возникает другое исключение, или тест завершается сбоем, если исключение не возникает. Для захвата любого из группы исключений в exception может передаваться кортеж, содержащий классы исключений.

Если заданы только аргументы exception и, возможно, msg, возвращается менеджер контекста, таким образом, код под тестированием может быть записан непосредственно, а не как функция:

with self.assertRaises(SomeException):
    do_something()

При использовании в качестве менеджера контекста assertRaises() принимает дополнительный ключевой аргумент msg.

Менеджер контекста будет хранить пойманный объект исключения в своем атрибуте exception. Это может быть полезно, если целью является выполнение дополнительных проверок на возникшее исключение:

with self.assertRaises(SomeException) as cm:
    do_something()

the_exception = cm.exception
self.assertEqual(the_exception.error_code, 3)

Изменено в версии 3.1: Добавлена возможность использования assertRaises() в качестве менеджера контекста.

Изменено в версии 3.2: Добавлен атрибут exception.

Изменено в версии 3.3: Добавлен ключевой аргумент msg при использовании в качестве менеджера контекста.

assertRaisesRegex(exception, regex, callable, *args, **kwds)

assertRaisesRegex(exception, regex, *, msg=None)

Подобно assertRaises(), но также проверяет, что regex соответствует строковому представлению возникшего исключения. regex может быть объектом регулярного выражения или строкой, содержащей регулярное выражение, подходящее для использования с re.search(). Примеры:

self.assertRaisesRegex(ValueError, "invalid literal for.*XYZ'$",
                       int, 'XYZ')

или:

with self.assertRaisesRegex(ValueError, 'literal'):
   int('XYZ')

Добавлен в версии 3.1: Добавлен под именем assertRaisesRegexp.

Изменено в версии 3.2: Переименовано в assertRaisesRegex().

Изменено в версии 3.3: Добавлен ключевой аргумент msg при использовании в качестве менеджера контекста.

assertWarns(warning, callable, *args, **kwds)

assertWarns(warning, *, msg=None)

Проверка, что при вызове callable с любыми позиционными или именованными аргументами, которые также переданы в assertWarns(), возникает предупреждение. Тест проходит, если предупреждение warning возникает, и терпит неудачу, если нет. Любое исключение является ошибкой. Для перехвата любого из набора предупреждений можно передать кортеж, содержащий классы предупреждений, как warnings.

Если указаны только аргументы warning и, возможно, msg, возвращается менеджер контекста, чтобы код, подлежащий тестированию, мог быть написан внутри, а не в качестве функции:

with self.assertWarns(SomeWarning):
    do_something()

При использовании в качестве менеджера контекста, assertWarns() принимает дополнительный именованный аргумент msg.

Менеджер контекста сохранит перехваченный объект предупреждения в своем warning атрибуте, а строку исходного кода, которая вызвала предупреждения, в filename и lineno атрибутах. Это может быть полезно, если целью является выполнение дополнительных проверок на пойманное предупреждение:

with self.assertWarns(SomeWarning) as cm:
    do_something()

self.assertIn('myfile.py', cm.filename)
self.assertEqual(320, cm.lineno)

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

Добавлен в версии 3.2.

Изменено в версии 3.3: Добавлен именованный аргумент msg при использовании в качестве менеджера контекста.

assertWarnsRegex(warning, regex, callable, *args, **kwds)

assertWarnsRegex(warning, regex, *, msg=None)

Как и assertWarns(), но также проверяет, что regex соответствует сообщению сгенерированного предупреждения. regex может быть объектом регулярного выражения или строкой, содержащей регулярное выражение, подходящее для использования с re.search(). Пример:

self.assertWarnsRegex(DeprecationWarning,
                      r'legacy_function\(\) is deprecated',
                      legacy_function, 'XYZ')

или:

with self.assertWarnsRegex(RuntimeWarning, 'unsafe frobnicating'):
    frobnicate('/etc/passwd')

Добавлен в версии 3.2.

Изменено в версии 3.3: Добавлен именованный аргумент msg при использовании в качестве менеджера контекста.

assertLogs(logger=None, level=None)

Менеджер контекста для проверки того, что хотя бы одно сообщение записывается в журнал logger или в одном из его дочерних элементов, по крайней мере, с указанным уровнем level.

Если задан, logger должен быть объектом logging.Logger или строкой, содержащей имя логгера. По умолчанию используется корневой логгер, который перехватывает все сообщения, которые не были заблокированы нераспространяющимся дочерним логгером.

Если задан, level должен быть либо числовым уровнем журнала, либо его строковым эквивалентом (например, либо "ERROR" , либо logging.ERROR). По умолчанию используется logging.INFO.

Тест проходит, если хотя бы одно сообщение, выведенное внутри with блока, соответствует условиям logger и level, в противном случае тест терпит неудачу.

Возвращаемый менеджером контекста объект является инструментом записи, который отслеживает совпадающие записи журнала. У него есть два атрибута:

records

Список объектов logging.LogRecord соответствующих записей журнала.

output

Список строк, содержащих отформатированный вывод соответствующих сообщений.

Пример:

with self.assertLogs('foo', level='INFO') as cm:
    logging.getLogger('foo').info('first message')
    logging.getLogger('foo.bar').error('second message')
self.assertEqual(cm.output, ['INFO:foo:first message',
                             'ERROR:foo.bar:second message'])

Добавлен в версии 3.4.

assertNoLogs(logger=None, level=None)

Менеджер контекста для проверки того, что в журнал logger или в один из его дочерних элементов не записываются сообщения с уровнем, по крайней мере, level.

Если задан, logger должен быть объектом logging.Logger или строкой, содержащей имя логгера. По умолчанию используется корневой логгер, который перехватывает все сообщения.

Если задан, level должен быть либо числовым уровнем журнала, либо его строковым эквивалентом (например, либо "ERROR" , либо logging.ERROR). По умолчанию используется logging.INFO.

В отличие от assertLogs(), менеджер контекста ничего не возвращает.

Добавлен в версии 3.10.

Также существуют другие методы для выполнения более специфических проверок, такие как:

Метод	Проверяет, что	Новый в
assertAlmostEqual(a, b)	round(a-b, 7) == 0
assertNotAlmostEqual(a, b)	round(a-b, 7) != 0
assertGreater(a, b)	a > b	3.1
assertGreaterEqual(a, b)	a >= b	3.1
assertLess(a, b)	a < b	3.1
assertLessEqual(a, b)	a <= b	3.1
assertRegex(s, r)	r.search(s)	3.1
assertNotRegex(s, r)	not r.search(s)	3.2
assertCountEqual(a, b)	a и b содержат одинаковые элементы в одинаковом количестве, независимо от их порядка.	3.2

assertAlmostEqual(first, second, places=7, msg=None, delta=None)

assertNotAlmostEqual(first, second, places=7, msg=None, delta=None)

Проверка, что first и second примерно (или не примерно) равны, вычисляя разницу, округляя до заданного количества десятичных знаков places (по умолчанию 7) и сравнивая с нулём. Обратите внимание, что эти методы округляют значения до заданного количества десятичных знаков (то есть как функция round()), а не значащих цифр.

Если указан delta вместо places, то разность между first и second должна быть меньше или равна (или больше) delta.

Если заданы оба delta и places, возникает TypeError.

Изменено в версии 3.2: assertAlmostEqual() автоматически считает объекты, сравниваемые равными, почти равными. assertNotAlmostEqual() автоматически терпит неудачу, если объекты сравниваются равными. Добавлен именованный аргумент delta.

assertGreater(first, second, msg=None)

assertGreaterEqual(first, second, msg=None)

assertLess(first, second, msg=None)

assertLessEqual(first, second, msg=None)

Проверка, что первое значение соответственно >, >=, < или <= второго значения в зависимости от имени метода. В противном случае тест завершится ошибкой:

>>> self.assertGreaterEqual(3, 4)
AssertionError: "3" unexpectedly not greater than or equal to "4"

Добавлен в версии 3.1.

assertRegex(text, regex, msg=None)

assertNotRegex(text, regex, msg=None)

Проверка, что поиск по regex соответствует (или не соответствует) тексту. В случае ошибки сообщение об ошибке будет включать шаблон и текст (или шаблон и часть текста, которая неожиданно соответствовала). regex может быть объектом регулярного выражения или строкой, содержащей регулярное выражение, подходящее для использования с re.search().

Добавлен в версии 3.1: Добавлен под именем assertRegexpMatches.

Изменено в версии 3.2: Метод assertRegexpMatches() был переименован в assertRegex().

Добавлен в версии 3.2: assertNotRegex().

assertCountEqual(first, second, msg=None)

Проверка, что последовательность первое содержит те же элементы, что и второе, независимо от их порядка. При их несовпадении будет сгенерировано сообщение об ошибке, в котором перечислены различия между последовательностями.

Дубликаты элементов не игнорируются при сравнении первого и второго. Проверяется, имеет ли каждый элемент одинаковое количество в обеих последовательностях. Эквивалентно: assertEqual(Counter(list(first)), Counter(list(second))), но также работает с последовательностями неизменяемых объектов.

Добавлен в версии 3.2.

Метод assertEqual() передает проверку равенства для объектов одного типа различным методам, специфичным для типа. Эти методы уже реализованы для большинства встроенных типов, но также можно зарегистрировать новые методы с помощью addTypeEqualityFunc():

addTypeEqualityFunc(typeobj, function)

Регистрирует метод, специфичный для типа, вызываемый методом assertEqual(), для проверки, равны ли два объекта одного и того же типа (не подклассы). function должен принимать два позиционных аргумента и необязательный аргумент msg=None, как и assertEqual(). Он должен вызывать исключение self.failureException(msg), если обнаруживается неравенство между первыми двумя параметрами — возможно, предоставляя полезную информацию и объяснение неравенств в сообщении об ошибке.

Добавлен в версии 3.1.

Список методов, специфичных для типа, которые автоматически используются методом assertEqual(), представлен в следующей таблице. Обратите внимание, что обычно нет необходимости вызывать эти методы напрямую.

Метод	Используется для сравнения	Добавлен в
assertMultiLineEqual(a, b)	строки	3.1
assertSequenceEqual(a, b)	последовательности	3.1
assertListEqual(a, b)	списки	3.1
assertTupleEqual(a, b)	кортежи	3.1
assertSetEqual(a, b)	множества или неизменяемые множества	3.1
assertDictEqual(a, b)	словари	3.1

assertMultiLineEqual(first, second, msg=None)

Проверка, что многострочная строка первая равна строке вторая. При несовпадении в сообщении об ошибке будет включена разница между двумя строками, выделяющая отличия. Этот метод используется по умолчанию при сравнении строк с помощью assertEqual().

Добавлен в версии 3.1.

assertSequenceEqual(first, second, msg=None, seq_type=None)

Проверка, что две последовательности равны. Если указан seq_type, то первая и вторая должны быть экземплярами seq_type, в противном случае будет выброшено исключение. Если последовательности отличаются, строится сообщение об ошибке, которое показывает разницу между ними.

Этот метод не вызывается напрямую методом assertEqual(), но используется для реализации assertListEqual() и assertTupleEqual().

Добавлен в версии 3.1.

assertListEqual(first, second, msg=None)

assertTupleEqual(first, second, msg=None)

Проверка, что два списка или кортежа равны. Если нет, строится сообщение об ошибке, которое показывает только различия между ними. Ошибка также возникает, если один из параметров имеет неправильный тип. Эти методы используются по умолчанию при сравнении списков или кортежей с помощью assertEqual().

Добавлен в версии 3.1.

assertSetEqual(first, second, msg=None)

Проверка, что два множества равны. Если нет, строится сообщение об ошибке, которое перечисляет различия между множествами. Этот метод используется по умолчанию при сравнении множеств или неизменяемых множеств с assertEqual().

Ошибка возникает, если у первого или второго нет метода set.difference().

Добавлен в версии 3.1.

assertDictEqual(first, second, msg=None)

Проверка, что два словаря равны. Если нет, строится сообщение об ошибке, которое показывает различия в словарях. Этот метод будет использоваться по умолчанию для сравнения словарей в вызовах assertEqual().

Добавлен в версии 3.1.

Наконец, TestCase предоставляет следующие методы и атрибуты:

fail(msg=None)

Безусловно сигнализирует об ошибке теста с msg или None в качестве сообщения об ошибке.

failureException

Этот атрибут класса задаёт исключение, генерируемое методом теста. Если тестовому фреймворку нужно использовать специализированное исключение, возможно, для переноса дополнительной информации, он должен быть подклассом этого исключения, чтобы «справедливо» работать со фреймворком. Исходное значение этого атрибута — AssertionError.

longMessage

Это атрибут класса, определяющий, что происходит, когда пользовательское сообщение об ошибке передается в качестве аргумента msg вызову assertXYY, который завершается ошибкой. True — значение по умолчанию. В этом случае пользовательское сообщение добавляется в конец стандартного сообщения об ошибке. При установке в значение False, пользовательское сообщение заменяет стандартное сообщение.

Настройка класса может быть переопределена в отдельных методах теста путём присвоения атрибуту экземпляра self.longMessage значения True или False перед вызовом методов assert.

Настройка класса сбрасывается перед каждым вызовом теста.

Добавлен в версии 3.1.

maxDiff

Этот атрибут контролирует максимальную длину различий, выводимых методами assert, которые сообщают о различиях при ошибке. По умолчанию он равен 80*8 символам. Методы assert, на которые влияет этот атрибут, это assertSequenceEqual() (включая все методы сравнения последовательностей, которые делегируют ему), assertDictEqual() и assertMultiLineEqual().

Установив maxDiff в None, вы отключаете ограничение максимальной длины различий.

Добавлен в версии 3.2.

Фреймворки тестирования могут использовать следующие методы для сбора информации о тесте:

countTestCases()

Возвращает количество тестов, представленных этим объектом теста. Для экземпляров TestCase это всегда 1.

defaultTestResult()

Возвращает экземпляр класса результатов теста, который должен использоваться для этого класса тестовых случаев (если другой экземпляр результатов не предоставляется методу run()).

Для экземпляров TestCase это всегда будет экземпляр TestResult; подклассы TestCase должны переопределять это по мере необходимости.

id()

Возвращает строку, идентифицирующую конкретный тестовый случай. Обычно это полное имя метода теста, включая имя модуля и класса.

shortDescription()

Возвращает описание теста или None, если описание не было предоставлено. По умолчанию этот метод возвращает первую строку docstring метода теста, если она доступна, или None.

Изменено в версии 3.1: В 3.1 это было изменено, чтобы добавить имя теста в краткое описание, даже при наличии docstring. Это вызвало проблемы совместимости с расширениями unittest, и добавление имени теста было перенесено в TextTestResult в Python 3.2.

addCleanup(function, /, *args, **kwargs)

Добавляет функцию, которая будет вызвана после tearDown() для очистки ресурсов, используемых во время теста. Функции будут вызваны в обратном порядке к порядку добавления (LIFO). Они вызываются с любыми аргументами и ключевыми аргументами, переданными в addCleanup() при их добавлении.

Если setUp() завершается ошибкой, что означает, что tearDown() не вызывается, то любые добавленные функции очистки всё равно будут вызваны.

Добавлен в версии 3.1.

enterContext(cm)

Входит в предоставленный менеджер контекста. При успешном завершении, также добавляет его метод __exit__() как функцию очистки с помощью addCleanup() и возвращает результат метода __enter__().

Добавлен в версии 3.11.

doCleanups()

Этот метод вызывается безусловно после tearDown(), или после setUp(), если setUp() вызывает исключение.

Он отвечает за вызов всех функций очистки, добавленных с помощью addCleanup(). Если вам нужно, чтобы функции очистки вызывались до tearDown(), то вы можете сами вызвать doCleanups().

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

Добавлен в версии 3.1.

classmethod addClassCleanup(function, /, *args, **kwargs)

Добавляет функцию, которая будет вызвана после tearDownClass() для очистки ресурсов, используемых во время класса теста. Функции будут вызваны в обратном порядке к порядку добавления (LIFO). Они вызываются с любыми аргументами и ключевыми аргументами, переданными в addClassCleanup() при их добавлении.

Если setUpClass() завершается ошибкой, что означает, что tearDownClass() не вызывается, то любые добавленные функции очистки всё равно будут вызваны.

Добавлен в версии 3.8.

classmethod enterClassContext(cm)

Входит в предоставленный менеджер контекста. При успешном завершении, также добавляет его метод __exit__() как функцию очистки с помощью addClassCleanup() и возвращает результат метода __enter__().

Добавлен в версии 3.11.

classmethod doClassCleanups()

Этот метод вызывается безусловно после tearDownClass(), или после setUpClass(), если setUpClass() вызывает исключение.

Он отвечает за вызов всех функций очистки, добавленных с помощью addClassCleanup(). Если вам нужно, чтобы функции очистки вызывались до tearDownClass(), то вы можете сами вызвать doClassCleanups().

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

Добавлен в версии 3.8.

class unittest.IsolatedAsyncioTestCase(methodName='runTest')

Этот класс предоставляет API, аналогичный TestCase, и также принимает корутины в качестве тестовых функций.

Добавлен в версии 3.8.

coroutine asyncSetUp()

Метод, вызываемый для подготовки тестового фикстура. Он вызывается после setUp(). Он вызывается непосредственно перед вызовом тестового метода; любое исключение, поднятое этим методом, помимо AssertionError или SkipTest, будет рассматриваться как ошибка, а не как сбой теста. По умолчанию реализация ничего не делает.

coroutine asyncTearDown()

Метод, вызываемый непосредственно после того, как был вызван тестовый метод и результат был записан. Он вызывается перед tearDown(). Он вызывается даже если тестовый метод поднял исключение, поэтому реализация в подклассах должна быть особенно внимательна к проверке внутреннего состояния. Любое исключение, помимо AssertionError или SkipTest, поднятое этим методом, будет рассматриваться как дополнительная ошибка, а не как сбой теста (тем самым увеличивая общее количество сообщенных ошибок). Этот метод будет вызван только в случае успешного выполнения asyncSetUp(), независимо от результата выполнения тестового метода. По умолчанию реализация ничего не делает.

addAsyncCleanup(function, /, *args, **kwargs)

Этот метод принимает корутину, которая может использоваться как функция очистки.

coroutine enterAsyncContext(cm)

Входит в предоставленный асинхронный менеджер контекста. В случае успеха, также добавляет его метод __aexit__() как функцию очистки с помощью addAsyncCleanup() и возвращает результат метода __aenter__().

Добавлен в версии 3.11.

run(result=None)

Создаёт новую событийную петлю для запуска теста, собирая результат в объект TestResult, переданный как result. Если result опущен или None, создаётся временный объект результата (вызывая метод defaultTestResult()) и используется. Объект результата возвращается вызывающей стороне run(). В конце теста все задачи в событийной петле отменяются.

Пример, иллюстрирующий порядок:

from unittest import IsolatedAsyncioTestCase

events = []


class Test(IsolatedAsyncioTestCase):


    def setUp(self):
        events.append("setUp")

    async def asyncSetUp(self):
        self._async_connection = await AsyncConnection()
        events.append("asyncSetUp")

    async def test_response(self):
        events.append("test_response")
        response = await self._async_connection.get("https://example.com")
        self.assertEqual(response.status_code, 200)
        self.addAsyncCleanup(self.on_cleanup)

    def tearDown(self):
        events.append("tearDown")

    async def asyncTearDown(self):
        await self._async_connection.close()
        events.append("asyncTearDown")

    async def on_cleanup(self):
        events.append("cleanup")

if __name__ == "__main__":
    unittest.main()

После выполнения теста, events будет содержать ["setUp", "asyncSetUp", "test_response", "asyncTearDown", "tearDown", "cleanup"].

class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)

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

Группировка тестов

class unittest.TestSuite(tests=())

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

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

Объекты TestSuite ведут себя очень похоже на объекты TestCase, за исключением того, что они фактически не реализуют тест. Вместо этого они используются для агрегирования тестов в группы тестов, которые должны выполняться вместе. Доступны некоторые дополнительные методы для добавления тестов к экземплярам TestSuite:

addTest(test)

Добавить TestCase или TestSuite в набор.

addTests(tests)

Добавить все тесты из итерируемого объекта экземпляров TestCase и TestSuite в этот набор тестов.

Это эквивалентно итерации по tests, вызову addTest() для каждого элемента.

Объект TestSuite разделяет следующие методы с объектом TestCase:

run(result)

Запустить тесты, связанные с этим набором, собрав результат в объект результата теста, переданный как result. Обратите внимание, что в отличие от TestCase.run(), TestSuite.run() требует передачи объекта результата.

debug()

Запустить тесты, связанные с этим набором, не собирая результат. Это позволяет исключениям, поднятым тестом, распространяться до вызывающей стороны и может использоваться для поддержки запуска тестов под отладчиком.

countTestCases()

Возвращает количество тестов, представленных этим объектом теста, включая все отдельные тесты и поднаборы.

__iter__()

Тесты, сгруппированные объектом TestSuite, всегда доступны итерацией. Подклассы могут лениво предоставлять тесты путём переопределения __iter__(). Обратите внимание, что этот метод может вызываться несколько раз для одного набора (например, при подсчёте тестов или сравнении на равенство), поэтому тесты, возвращаемые повторными итерациями перед TestSuite.run(), должны быть одинаковыми для каждой итерации вызова. После TestSuite.run(), вызывающие стороны не должны полагаться на тесты, возвращаемые этим методом, если вызывающая сторона не использует подкласс, переопределяющий TestSuite._removeTestAtIndex() для сохранения ссылок на тесты.

Изменено в версии 3.2: В предыдущих версиях TestSuite обращался к тестам напрямую, а не через итерацию, поэтому переопределение __iter__() не было достаточным для предоставления тестов.

Изменено в версии 3.4: В предыдущих версиях TestSuite хранил ссылки на каждый TestCase после TestSuite.run(). Подклассы могут восстановить это поведение, переопределив TestSuite._removeTestAtIndex().

В типичном использовании объекта TestSuite метод run() вызывается TestRunner а не конечным пользовательским набором инструментов для тестов.

Загрузка и выполнение тестов

class unittest.TestLoader

Класс TestLoader используется для создания наборов тестов из классов и модулей. Обычно нет необходимости создавать экземпляр этого класса; модуль unittest предоставляет экземпляр, который можно использовать совместно как unittest.defaultTestLoader. Однако, использование подкласса или экземпляра позволяет настроить некоторые конфигурируемые свойства.

Объекты TestLoader имеют следующие атрибуты:

errors

Список некритических ошибок, возникших при загрузке тестов. Не сбрасывается загрузчиком ни на одном этапе. Критические ошибки сигнализируются соответствующим методом, который генерирует исключение для вызывающей стороны. Некритические ошибки также указываются синтетическим тестом, который будет генерировать исходную ошибку при выполнении.

Добавлен в версии 3.5.

Объекты TestLoader имеют следующие методы:

loadTestsFromTestCase(testCaseClass)

Возвращает набор всех тестовых случаев, содержащихся в testCaseClass, производном от TestCase.

Экземпляр тестового случая создается для каждого метода, имя которого указано в getTestCaseNames(). По умолчанию это имена методов, начинающиеся с test. Если getTestCaseNames() не возвращает никаких методов, но метод runTest() реализован, вместо этого создается один тестовый случай для этого метода.

loadTestsFromModule(module, *, pattern=None)

Возвращает набор всех тестовых случаев, содержащихся в указанном модуле. Этот метод ищет в module классы, производные от TestCase, и создает экземпляр класса для каждого тестового метода, определенного для класса.

Примечание

Использование иерархии классов, производных от TestCase, может быть удобным для совместного использования фикстур и вспомогательных функций, но определение тестовых методов в базовых классах, которые не предназначены для непосредственного создания экземпляров, не работает с этим методом. Тем не менее, это может быть полезно, когда фикстуры различны и определены в подклассах.

Если модуль предоставляет функцию load_tests, она будет вызвана для загрузки тестов. Это позволяет модулям настраивать загрузку тестов. Это протокол load_tests. Аргумент pattern передается в качестве третьего аргумента в load_tests.

Изменено в версии 3.2: Добавлена поддержка load_tests.

Изменено в версии 3.5: Добавлен аргумент pattern только с ключевыми словами.

Изменено в версии 3.12: Устранён недокументированный и неофициальный параметр use_load_tests.

loadTestsFromName(name, module=None)

Возвращает набор всех тестовых случаев, заданных строковым спецификатором.

Спецификатор name — это «точечное имя», которое может ссылаться на модуль, класс тестового случая, тестовый метод внутри класса тестового случая, экземпляр TestSuite или вызываемый объект, возвращающий экземпляр TestCase или TestSuite. Эти проверки применяются в указанном порядке; то есть, метод возможного класса тестового случая будет выбран как «метод теста внутри класса тестового случая», а не как «вызываемый объект».

Например, если у вас есть модуль SampleTests , содержащий производный от TestCase класс SampleTestCase с тремя тестовыми методами (test_one(), test_two(), и test_three()), спецификатор 'SampleTests.SampleTestCase' заставит этот метод вернуть набор, который выполнит все три тестовых метода. Использование спецификатора 'SampleTests.SampleTestCase.test_two' заставит его вернуть набор тестов, которые выполнят только тестовый метод test_two().

Спецификатор может ссылаться на модули и пакеты, которые еще не импортированы; они будут импортированы как побочный эффект.

Метод необязательно разрешает name относительно данного module.

Изменено в версии 3.5: Если во время обхода name возникает ImportError или AttributeError, тогда возвращается синтетический тест, который поднимает эту ошибку при выполнении. Эти ошибки включаются в ошибки, накапливаемые self.errors.

loadTestsFromNames(names, module=None)

Аналогично loadTestsFromName(), но принимает последовательность имён вместо одного имени. Возвращаемое значение — набор тестов, который поддерживает все тесты, определенные для каждого имени.

getTestCaseNames(testCaseClass)

Возвращает отсортированную последовательность имён методов, найденных в testCaseClass; это должен быть подкласс TestCase.

discover(start_dir, pattern='test*.py', top_level_dir=None)

Находит все тестовые модули, рекурсивно обходя подкаталоги из указанной стартовой директории, и возвращает объект TestSuite, содержащий их. Будут загружаться только те тестовые файлы, которые соответствуют pattern (используется синтаксис шаблонов оболочки). Будут загружаться только имена модулей, которые являются импортируемыми (т. е. являются допустимыми идентификаторами Python).

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

Если импорт модуля завершается неудачей, например, из-за синтаксической ошибки, то это будет записано как одна ошибка, и обнаружение продолжится. Если неудача импорта вызвана поднятием SkipTest, это будет записано как пропуск, а не ошибка.

Если найден пакет (директория, содержащая файл с именем __init__.py), пакет будет проверен на наличие функции load_tests . Если она существует, то она будет вызвана package.load_tests(loader, tests, pattern). Обнаружение тестов позаботится о том, чтобы пакет проверялся на наличие тестов только один раз во время вызова, даже если функция load_tests сама вызывает loader.discover.

Если load_tests существует, обнаружение не рекурсивно входит в пакет; load_tests отвечает за загрузку всех тестов в пакете.

Шаблон намеренно не сохраняется как атрибут загрузчика, чтобы пакеты могли продолжить обнаружение сами.

top_level_dir хранится во внутреннем виде и используется в качестве значения по умолчанию для любых вложенных вызовов discover(). То есть, если load_tests пакета вызывает loader.discover(), ему не нужно передавать этот аргумент.

start_dir может быть как точечным именем модуля, так и директорией.

Добавлен в версии 3.2.

Изменено в версии 3.4: Модули, которые поднимают SkipTest при импорте, записываются как пропуска, а не ошибки.

Изменено в версии 3.4: start_dir может быть пространством имён пакетов.

Изменено в версии 3.4: Пути сортируются перед импортом, чтобы порядок выполнения был одинаковым, даже если порядок на основе файловой системы не зависит от имени файла.

Изменено в версии 3.5: Найденные пакеты теперь проверяются на наличие load_tests независимо от того, соответствует ли их путь pattern, потому что имя пакета не может соответствовать шаблону по умолчанию.

Изменено в версии 3.11: start_dir не может быть пространством имён пакетов. Это было нарушено с Python 3.7, а в Python 3.11 это было официально удалено.

Изменено в версии 3.12.4: top_level_dir хранится только на время вызова discover.

Следующие атрибуты TestLoader можно настроить, либо создав подкласс, либо присвоив значение экземпляру:

testMethodPrefix

Строка, задающая префикс имён методов, которые будут интерпретироваться как тестовые методы. Значение по умолчанию — 'test'.

Это влияет на getTestCaseNames() и все loadTestsFrom* методы.

sortTestMethodsUsing

Функция, используемая для сравнения имён методов при их сортировке в getTestCaseNames() и всех loadTestsFrom* методах.

suiteClass

Объект вызываемого типа, который строит набор тестов из списка тестов. Методы на результирующем объекте не требуются. Значение по умолчанию — класс TestSuite.

Это влияет на все loadTestsFrom* методы.

testNamePatterns

Список шаблонов имён тестов в стиле Unix-оболочек с подстановкой, которым должны соответствовать тестовые методы, чтобы быть включёнными в наборы тестов (см. опцию -k).

Если этот атрибут не пустой (значение по умолчанию), все тестовые методы, которые должны быть включены в наборы тестов, должны соответствовать одному из шаблонов в этом списке. Обратите внимание, что сопоставление всегда выполняется с помощью fnmatch.fnmatchcase(), поэтому, в отличие от шаблонов, переданных в опцию -k, простые шаблоны подстрок должны быть преобразованы с использованием * подстановочных знаков.

Это влияет на все loadTestsFrom* методы.

Добавлен в версии 3.7.

class unittest.TestResult

Этот класс используется для сбора информации о том, какие тесты прошли успешно, а какие потерпели неудачу.

Объект TestResult хранит результаты набора тестов. Классы TestCase и TestSuite гарантируют, что результаты записываются должным образом; авторы тестов не должны беспокоиться о записи результатов тестов.

Фреймворки тестирования, построенные поверх unittest, могут захотеть получить доступ к объекту TestResult, сгенерированному при запуске набора тестов, для целей отчетности; экземпляр TestResult возвращается методом TestRunner.run() для этой цели.

Экземпляры TestResult обладают следующими атрибутами, которые будут интересны при проверке результатов выполнения набора тестов:

errors

Список, содержащий 2-кортежи экземпляров TestCase и строк, содержащих отформатированные трассировки стека. Каждая пара представляет тест, который вызвал непредвиденное исключение.

failures

Список, содержащий 2-кортежи экземпляров TestCase и строк, содержащих отформатированные трассировки стека. Каждая пара представляет тест, в котором явно было указано отклонение, используя методы assert* methods.

skipped

Список, содержащий 2-кортежи экземпляров TestCase и строк, содержащих причину пропуска теста.

Добавлен в версии 3.1.

expectedFailures

Список, содержащий 2-кортежи экземпляров TestCase и строк, содержащих отформатированные трассировки стека. Каждая пара представляет ожидаемую неудачу или ошибку тестового случая.

unexpectedSuccesses

Список, содержащий экземпляры TestCase, которые были помечены как ожидаемые сбои, но прошли успешно.

collectedDurations

Список, содержащий 2-кортежи имён тестовых случаев и чисел с плавающей точкой, представляющих затраченное время каждого проведённого теста.

Добавлен в версии 3.12.

shouldStop

Устанавливается в True, когда выполнение тестов должно быть прервано методом stop().

testsRun

Общее количество выполненных тестов.

buffer

Если установлено в true, sys.stdout и sys.stderr будут буферизованы между вызовами startTest() и stopTest(). Собраный вывод будет отображён на реальный sys.stdout и sys.stderr только при сбоях или ошибках теста. Любой вывод также прикреплён к сообщению об ошибке / сбое.

Добавлен в версии 3.2.

failfast

Если установлено в true, stop() будет вызван при первой ошибке или сбое, останавливая запуск теста.

Добавлен в версии 3.2.

tb_locals

Если установлено в true, локальные переменные будут показаны в трассировках стека.

Добавлен в версии 3.5.

wasSuccessful()

Возвращает True, если все выполненные тесты прошли успешно, в противном случае возвращает False.

Изменено в версии 3.4: Возвращает False, если были какие-либо unexpectedSuccesses от тестов, помеченных декоратором expectedFailure().

stop()

Этот метод может быть вызван для сигнализации о том, что набор выполняемых тестов должен быть прерван, установив атрибут shouldStop в True. Объекты TestRunner должны учитывать этот флаг и возвращаться без выполнения дополнительных тестов.

Например, эта функция используется классом TextTestRunner для остановки фреймворка тестирования, когда пользователь сигнализирует об прерывании с клавиатуры. Интерактивные инструменты, которые предоставляют реализации TestRunner, могут использовать это аналогичным образом.

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

startTest(test)

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

stopTest(test)

Вызывается после того, как тестовый случай test был выполнен, независимо от результата.

startTestRun()

Вызывается один раз перед выполнением любых тестов.

Добавлен в версии 3.1.

stopTestRun()

Вызывается один раз после выполнения всех тестов.

Добавлен в версии 3.1.

addError(test, err)

Вызывается, когда тестовый случай test вызывает непредвиденное исключение. err — кортеж, возвращаемый sys.exc_info(): (type, value, traceback).

Стандартная реализация добавляет кортеж (test, formatted_err) в атрибут errors экземпляра, где formatted_err — отформатированная трассировка стека, полученная из err.

addFailure(test, err)

Вызывается, когда тестовый случай test указывает на ошибку. err — кортеж, возвращаемый sys.exc_info(): (type, value, traceback).

Стандартная реализация добавляет кортеж (test, formatted_err) в атрибут failures экземпляра, где formatted_err — отформатированная трассировка стека, полученная из err.

addSuccess(test)

Вызывается, когда тестовый случай test выполняется успешно.

Стандартная реализация ничего не делает.

addSkip(test, reason)

Вызывается, когда тестовый случай test пропускается. reason — причина пропуска теста.

Стандартная реализация добавляет кортеж (test, reason) в атрибут skipped экземпляра.

addExpectedFailure(test, err)

Вызывается, когда тестовый случай test завершается ошибкой или сгенерировал исключение, но был помечен декоратором expectedFailure().

По умолчанию реализация добавляет кортеж (test, formatted_err) в атрибут экземпляра expectedFailures, где formatted_err — отформатированный traceback, полученный из err.

addUnexpectedSuccess(test)

Вызывается, когда тестовый случай test был помечен декоратором expectedFailure(), но завершился успешно.

По умолчанию реализация добавляет тест в атрибут экземпляра unexpectedSuccesses.

addSubTest(test, subtest, outcome)

Вызывается, когда подтест завершается. test — тестовый случай, соответствующий методу теста. subtest — экземпляр пользовательского класса TestCase, описывающий подтест.

Если outcome равен None, подтест завершился успешно. В противном случае он завершился ошибкой, где outcome — кортеж, возвращаемый функцией sys.exc_info(): (type, value, traceback).

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

Добавлен в версии 3.4.

addDuration(test, elapsed)

Вызывается, когда тестовый случай завершается. elapsed — время в секундах, включающее выполнение функций очистки.

Добавлен в версии 3.12.

class unittest.TextTestResult(stream, descriptions, verbosity, *, durations=None)

Конкретная реализация TestResult, используемая TextTestRunner. Подклассы должны принимать **kwargs для обеспечения совместимости по мере изменения интерфейса.

Добавлен в версии 3.2.

Изменено в версии 3.12: Добавлен параметр durations.

unittest.defaultTestLoader

Экземпляр класса TestLoader, предназначенный для совместного использования. Если не требуется настройка TestLoader, этот экземпляр можно использовать вместо многократного создания новых экземпляров.

class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False, durations=None)

Базовая реализация запуска тестов, выводящая результаты в поток. Если stream имеет значение None, по умолчанию используется sys.stderr в качестве потока вывода. Этот класс имеет несколько настраиваемых параметров, но в основном очень прост. Приложения с графическим интерфейсом, которые запускают наборы тестов, должны предоставить альтернативные реализации. Такие реализации должны принимать **kwargs для обеспечения совместимости по мере изменения интерфейса для создания запускателей при добавлении функций в unittest.

По умолчанию этот запускатель отображает DeprecationWarning, PendingDeprecationWarning, ResourceWarning и ImportWarning, даже если они по умолчанию игнорируются. Это поведение можно переопределить, используя опции Python -Wd или -Wa (см. Управление предупреждениями) и оставляя warnings для None.

Изменено в версии 3.2: Добавлен параметр warnings.

Изменено в версии 3.2: По умолчанию поток устанавливается в sys.stderr во время создания экземпляра, а не во время импорта.

Изменено в версии 3.5: Добавлен параметр tb_locals.

Изменено в версии 3.12: Добавлен параметр durations.

_makeResult()

Этот метод возвращает экземпляр TestResult, используемый методом run(). Он не предназначен для прямого вызова, но может быть переопределён в подклассах для предоставления настраиваемого TestResult.

_makeResult() создаёт экземпляр класса или вызываемого объекта, переданного в конструктор TextTestRunner в качестве аргумента resultclass . По умолчанию используется TextTestResult, если не предоставлен resultclass . Класс результата создаётся со следующими аргументами:

stream, descriptions, verbosity

run(test)

Этот метод — основной публичный интерфейс для TextTestRunner. Этот метод принимает экземпляр TestSuite или TestCase. Создается экземпляр TestResult с помощью вызова _makeResult(), и тесты выполняются, а результаты выводятся в stdout.

unittest.main(module='__main__', defaultTest=None, argv=None, testRunner=None, testLoader=unittest.defaultTestLoader, exit=True, verbosity=1, failfast=None, catchbreak=None, buffer=None, warnings=None)

Программа командной строки, которая загружает набор тестов из модуля и выполняет их; это в основном для удобного запуска модулей тестов. Самое простое использование этой функции заключается в добавлении следующей строки в конец скрипта теста:

if __name__ == '__main__':
    unittest.main()

Вы можете запустить тесты с более подробной информацией, передав аргумент verbosity:

if __name__ == '__main__':
    unittest.main(verbosity=2)

Аргумент defaultTest — это имя одного теста или итерируемый набор имён тестов для выполнения, если имена тестов не указаны через argv. Если не указан или None и имена тестов не предоставлены через argv, выполняются все тесты, найденные в модуле.

Аргумент argv может быть списком опций, переданных программе, где первый элемент — имя программы. Если не указан или None, используются значения sys.argv.

Аргумент testRunner может быть классом тестового исполнителя или уже созданным экземпляром. По умолчанию main вызывает sys.exit() с кодом выхода, указывающим успех (0) или неудачу (1) выполненных тестов. Код выхода 5 указывает, что тесты не выполнялись или были пропущены.

Аргумент testLoader должен быть экземпляром TestLoader и по умолчанию равен defaultTestLoader.

main поддерживает использование в интерактивном интерпретаторе путём передачи аргумента exit=False. Это отображает результат на стандартном выходе без вызова sys.exit():

>>> from unittest import main
>>> main(module='test_module', exit=False)

Параметры failfast, catchbreak и buffer имеют тот же эффект, что и одноимённые опции командной строки.

Аргумент warnings указывает фильтр предупреждений, который должен использоваться во время выполнения тестов. Если он не указан, он останется None если опция -W передаётся в python (см. Управление предупреждениями), иначе он будет установлен в 'default'.

Вызов main возвращает объект с атрибутом result, который содержит результат выполнения тестов в виде unittest.TestResult.

Изменено в версии 3.1: Добавлен параметр exit.

Изменено в версии 3.2: Добавлены параметры verbosity, failfast, catchbreak, buffer и warnings.

Изменено в версии 3.4: Параметр defaultTest был изменён для поддержки итерируемых наборов имён тестов.

load_tests(loader, standard_tests, pattern)

test_cases = (TestCase1, TestCase2, TestCase3)

def load_tests(loader, tests, pattern):
    suite = TestSuite()
    for test_class in test_cases:
        tests = loader.loadTestsFromTestCase(test_class)
        suite.addTests(tests)
    return suite

load_tests(loader, standard_tests, pattern)

def load_tests(loader, standard_tests, pattern):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

setUpClass и tearDownClass

Эти методы должны быть реализованы как методы класса:

import unittest

class Test(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        cls._connection = createExpensiveConnectionObject()

    @classmethod
    def tearDownClass(cls):
        cls._connection.destroy()

Если вы хотите, чтобы setUpClass и tearDownClass были вызваны для базовых классов, то вы должны вызвать их сами. Реализации в TestCase пусты.

Если во время setUpClass возникает исключение, то тесты в классе не выполняются, и tearDownClass не выполняется. У пропущенных классов не будет выполняться setUpClass или tearDownClass. Если исключение является исключением SkipTest, то класс будет сообщен как пропущенный, а не как ошибка.

setUpModule и tearDownModule

Эти методы должны быть реализованы как функции:

def setUpModule():
    createConnection()

def tearDownModule():
    closeConnection()

Если во время setUpModule возникает исключение, то ни один из тестов в модуле не будет выполнен, и tearDownModule не будет выполнен. Если исключение является исключением SkipTest, то модуль будет сообщен как пропущенный, а не как ошибка.

Для добавления кода очистки, который должен быть выполнен даже в случае возникновения исключения, используйте addModuleCleanup:

unittest.addModuleCleanup(function, /, *args, **kwargs)

Добавить функцию, которая будет вызываться после tearDownModule() для очистки ресурсов, используемых во время класса теста. Функции будут вызываться в обратном порядке к порядку их добавления (LIFO). Они вызываются с любыми аргументами и ключевыми аргументами, переданными в addModuleCleanup() при их добавлении.

Если setUpModule() терпит неудачу, что означает, что tearDownModule() не вызывается, то любые добавленные функции очистки все равно будут вызваны.

Добавлена в версии 3.8.

classmethod unittest.enterModuleContext(cm)

Войти в предоставленный менеджер контекста. Если успешно, также добавить его метод __exit__() как функцию очистки с помощью addModuleCleanup() и вернуть результат метода __enter__().

Добавлена в версии 3.11.

unittest.doModuleCleanups()

Эта функция вызывается безусловно после tearDownModule(), или после setUpModule() если setUpModule() вызывает исключение.

Она отвечает за вызов всех функций очистки, добавленных с помощью addModuleCleanup(). Если вам нужны функции очистки, которые должны быть вызваны до tearDownModule(), то вы можете вызвать doModuleCleanups() сами.

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

Добавлена в версии 3.8.