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

Показывать локальные переменные в трассировках.

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

Объекты тестовых случаев

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 предоставляет несколько методов утверждения для проверки и отчета об ошибках. В следующей таблице перечислены наиболее часто используемые методы (более подробный список см. в таблицах ниже):

Метод	Проверяет, что	Введено в
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

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)

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

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

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

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

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

records

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

output

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

Пример:

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.

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

Метод	Проверяет, что	Введено в
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 приблизительно (или не приблизительно) равны, вычисляя разницу, округляя до заданного количества десятичных знаков (по умолчанию 7) и сравнивая с нулём. Обратите внимание, что эти методы округляют значения до заданного числа десятичных знаков (как функция round()), а не значимых цифр.

Если вместо places передаётся delta, то разность между 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)

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

>>> 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().

Введено в версии 3.5: Имя assertNotRegexpMatches — устаревший псевдоним для assertNotRegex().

assertCountEqual(first, second, msg=None)

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

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

Введено в версии 3.2.

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

addTypeEqualityFunc(typeobj, function)

Регистрирует метод, специфичный для типа, вызываемый assertEqual(), для проверки, сравниваются ли два объекта одного и того же typeobj (не подклассы) как равные. 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)

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

Новый в версии 3.1.

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

Проверяет, что две последовательности равны. Если указан seq_type, то оба first и second должны быть экземплярами 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().

Возникает ошибка, если у first или second нет метода 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 если описание не предоставлено. По умолчанию этот метод возвращает первую строку документа строки метода теста, если она доступна, или None.

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

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

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

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

Новый в версии 3.1.

doCleanups()

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

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

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

Новое в версии 3.1.

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

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

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

Новое в версии 3.8.

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)

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

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)

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

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

loadTestsFromModule(module, pattern=None)

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

Примечание

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

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

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

Изменено в версии 3.5: Недокументированный и неофициальный необязательный аргумент use_load_tests устарел и игнорируется, хотя он по-прежнему принимается для обратной совместимости. Метод также теперь принимает ключевой аргумент pattern, который передаётся 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).

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

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

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

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

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

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

Введено в версии 3.2.

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

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

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

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

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

testMethodPrefix

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

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

sortTestMethodsUsing

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

suiteClass

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

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

testNamePatterns

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

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

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

New in version 3.7.

class unittest.TestResult

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

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

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

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

errors

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

failures

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

skipped

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

Новое в версии 3.1.

expectedFailures

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

unexpectedSuccesses

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

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 — отформатированная трассировка, полученная из err.

addUnexpectedSuccess(test)

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

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

addSubTest(test, subtest, outcome)

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

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

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

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

class unittest.TextTestResult(stream, descriptions, verbosity)

Конкретная реализация TestResult, используемая TextTestRunner.

Добавлена в версии 3.2: Этот класс ранее назывался _TextTestResult. Старое имя всё ещё существует как псевдоним, но устарело.

unittest.defaultTestLoader

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

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

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

По умолчанию этот исполнитель показывает DeprecationWarning, PendingDeprecationWarning, ResourceWarning и ImportWarning, даже если они по умолчанию игнорируются. Предупреждения об устаревании, вызванные устаревшими методами unittest, также обрабатываются особым образом, и, когда фильтры предупреждений — 'default' или 'always', они будут отображаться только один раз на модуль, чтобы избежать слишком большого количества сообщений об ошибках. Это поведение можно переопределить с помощью параметров Python -Wd или -Wa (см. Управление предупреждениями) и оставить warnings равным None.

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

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

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

_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)

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

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

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

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

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

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

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

Аргумент 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 фактически возвращает экземпляр класса TestProgram. Это хранит результат проведённых тестов как атрибут result.

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

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

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

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.

unittest.doModuleCleanups()

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

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

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

Новое в версии 3.8.