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

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

Список объектов 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 соответствует (или не соответствует) text. В случае неудачи сообщение об ошибке будет включать шаблон и text (или шаблон и часть text, которая неожиданно совпала). 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(), для проверки, сравниваются ли два объекта одного и того же типа (не подклассы) на равенство. 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)

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

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

loadTestsFromModule(module, pattern=None)

Возвращает набор всех тестовых случаев, содержащихся в указанном модуле. Этот метод ищет в модуле классы, производные от 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 относительно данного модуля.

Изменено в версии 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*().

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

class unittest.TestResult

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

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

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

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

errors

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

failures

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

skipped

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

Новая функция в версии 3.1.

expectedFailures

Список, содержащий пары (экземпляр 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(), и тесты запускаются, а результаты выводятся в стандартный вывод.

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() вызывает исключение.

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

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

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