unittest — Фреймворк юнит тестирования

Исходный код: Lib/unittest/__init__.py

---

(Если вы уже знакомы с основными концепциями тестирования, вы можете перейти к списоку методов утверждения.)

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

Для этого unittest поддерживает некоторые важные концепции в объектно- ориентированном ключе:

тестовая фикстура

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

тестовый случай

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

тестовый набор

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

запускальшик теста

teзапускальшик теста является компонентом, который управляет выполнением тестов и предоставляет результат пользователю. Питатель может использовать графический интерфейс, текстовый интерфейс или возвращает специальный значение для указания результатов выполнения тестов.

См.также

Модуль doctest

Другой модуль тестовой поддержки с совершенно другим вкусом.

Простое тестирование Smalltalk: с шаблонами

Оригинальная статья Кента Бека (Kent Beck’s) о тестирующих фреймворках с использованием шаблона, совместно используемого unittest.

pytest

Сторонние фреймворк unittest с более легким синтаксисом для написания тестов. Например, assert func(10) == 42.

Таксономия инструментов тестирования Python

Обширный список Python инструментов тестирования, включая функциональные фреймворков тестирования и библиотеки объектов mock.

Тестирование в списке рассылки Python

Специальная группа для обсуждения тестирования и инструментов тестирования в Python.

Сценарий Tools/unittestgui/unittestgui.py в дистрибутиве исходного кода Python представляет собой инструмент с графическим интерфейсом для обнаружения и выполнения тестов. Это в основном предназначено для простоты использования для новичков в юнит тестировании. Для производственных сред рекомендуется проводить тесты с помощью системы непрерывной интеграции, такой как Buildbot, Jenkins, Travis-CI или AppVeyor.

Базовый пример

Модуль unittest предоставляет широкий набор инструментов для построения и выполнения тестов. В этом разделе показано, что небольшой набор инструментов достаточен для удовлетворения потребностей большинства пользователей.

Вот короткий сценарий для тестирования трех строковых методов:

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # проверить, что s.split не работает, если разделитель не является строкой
        with self.assertRaises(TypeError):
            s.split(2)

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

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

Суть каждого теста - это вызов assertEqual() для проверки ожидаемого результата; assertTrue() или assertFalse() для проверки состояния; или assertRaises(), чтобы проверить, что возникает определенное исключение. Эти методы используемый вместо assert инструкция поэтому бегун может накапливать все результаты теста и создавать отчет.

Методы setUp() и tearDown() позволяют определить инструкции, которые будут выполняться до и после каждого метода тестирования. Более подробно они описаны в разделе Организация тестового кода.

Последний блок показывает простой способ выполнения тестов. unittest.main() обеспечивает интерфейс командной строки для тестового сценария. При запуске из командной строки приведенный выше сценарий создает выходные данные, которые выглядят следующим образом:

...
----------------------------------------------------------------------
Ran 3 tests in 0.000s

OK

Передача опции -v в тестовый сценарий даст команду unittest.main() включить более высокий уровень детализации и выдаст следующий результат:

test_isupper (__main__.TestStringMethods) ... ok
test_split (__main__.TestStringMethods) ... ok
test_upper (__main__.TestStringMethods) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

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

Интерфейс командной строки

Модуль unittest можно используемый из командной строки для выполнения тестов из модулей, классов или даже отдельных методов тестирования:

python -m unittest test_module1 test_module2
python -m unittest test_module.TestClass
python -m unittest test_module.TestClass.test_method

Можно передать список с любой комбинацией имен модулей и полных имен классов или методов.

Тестовые модули также могут быть определены путем к файлу:

python -m unittest tests/test_something.py

Это позволяет использовать завершение имени файла оболочки для указания тестового модуля. Указанный файл по-прежнему должен быть импортирован как модуль. Путь преобразуется в имя модуля путем удаления „.py“ и преобразования разделителей пути в „.“. Если требуется выполнить тестовый файл, который не может быть импортирован как модуль, необходимо выполнить файл непосредственно.

Можно выполнять тесты с большей детализацией (более высокой степенью детализации), передав флаг -v:

python -m unittest -v test_module

При выполнении без аргументов запускается Обнаружение тестов:

python -m unittest

Список всех параметров командной строки:

python -m unittest -h

Изменено в версии 3.2: В более ранних версиях можно было запускать только индивидуальные методы тестирования, а не модули или классы.

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

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

-b, --buffer

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

-c, --catch

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

Отображение переменных локальная в трейсбэки.

Добавлено в версии 3.2: Добавлены параметры командной строки -b, -c и -f.

Добавлено в версии 3.5: Параметр командной строки --locals.

Добавлено в версии 3.7: Параметр командной строки -k.

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

Обнаружение тестов

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

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

Тестовое обнаружение реализовано в TestLoader.discover(), но также может быть используемый из командной строки. Основное использование командной строки::

cd project_directory
python -m unittest discover

Примечание

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

Подкоманда discover имеет следующие опции:

-v, --verbose

Подробный вывод

-s, --start-directory directory

Каталог для запуска обнаружения (. по умолчанию)

-p, --pattern pattern

Шаблон для сопоставления с тестовыми файлами (test*.py по умолчанию)

-t, --top-level-directory directory

Каталог верхнего уровня проекта (по умолчанию - начальный каталог)

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

python -m unittest discover -s project_directory -p "*_test.py"
python -m unittest discover project_directory "*_test.py"

Помимо пути, можно передать имя пакета, например myproject.subpackage.test, в качестве начального каталога. Указанное имя пакета будет импортировано, а его местоположение в файловой системе будет используемый в качестве начального каталога.

Осторожно

Обнаружение тестов загружает тесты, импортируя их. Как только обнаружение теста обнаружит все тестовые файлы из указанного начального каталога, он превратит пути в имена пакетов для импорта. Например, foo/bar/baz.py будут импортированы как foo.bar.baz.

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

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

Модули и пакеты тестирования могут настраивать загрузку и обнаружение тестов с помощью load_tests протокол.

Изменено в версии 3.4: Обнаружение тестов поддерживает пакеты пространства имен.

Организация тестового кода

Основными компоновочными блоками юнит тестирования являются тестовые случаи — отдельные сценарии, которые должны быть настроены и проверены на правильность. В unittest тестовые случаи представлены unittest.TestCase сущности. Для создания собственных тестовых примеров необходимо написать подклассы TestCase или использовать FunctionTestCase.

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

Простейший TestCase подкласс просто реализует метод тестирования (т.е. метод, имя которого начинается с test) для выполнения конкретных код тестирования:

import unittest

class DefaultWidgetSizeTestCase(unittest.TestCase):
    def test_default_widget_size(self):
        widget = Widget('The widget')
        self.assertEqual(widget.size(), (50, 50))

Заметим, что для того, чтобы что-то проверить, мы используем один из assert*() методов, предоставляемых базовым классом TestCase. Если тест завершается неуспешно, создается исключение с пояснительным сообщением, и unittest идентифицирует тестовый случай как failure. Любые другие исключения будут рассматриваться как errors.

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

import unittest

class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def test_default_widget_size(self):
        self.assertEqual(self.widget.size(), (50,50),
                         'incorrect default size')

    def test_widget_resize(self):
        self.widget.resize(100,150)
        self.assertEqual(self.widget.size(), (100,150),
                         'wrong size after resize')

Примечание

Порядок выполнения различных тестов определяется сортировкой имен методов тестирования относительно встроенного порядка строки.

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

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

import unittest

class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def tearDown(self):
        self.widget.dispose()

Если setUp() выполнена успешно, будет выполняться tearDown(), был ли успешно выполнен метод тестирования.

Такая рабочая среда для тестового код называется тест фикстура. Для выполнения каждого отдельного метода тестирования создается новый сущность, представляющий собой уникальный используемый тестовой фикстуры. Таким образом, setUp(), tearDown() и __init__() будут вызываться один раз за тест.

Для группирования тестов в соответствии с тестируемыми функциями рекомендуется использовать их реализации. unittest обеспечивает механизм для этого: тестовый набор, представленный классом TestSuite unittest. В большинстве случаев вызов unittest.main() делает правильные вещи и собирает все тестовые примеры модуля для вас и выполняет их.

Однако, если вы хотите настроить здание вашего набора тестов, вы можете сделать это самостоятельно:

def suite():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_widget_size'))
    suite.addTest(WidgetTestCase('test_widget_resize'))
    return suite

if __name__ == '__main__':
    runner = unittest.TextTestRunner()
    runner.run(suite())

Определения тестовых примеров и наборов тестов можно поместить в те же модули, что и код, которые они должны тестировать (например, widget.py), но есть несколько преимуществ размещения тестовых код в отдельном модуле, например, test_widget.py:

• Тестовый модуль можно запустить автономно из командной строки.
• Тестовый код легче отделить от поставляемого код.
• Меньше соблазнов менять тест код подгонять его под код без уважительной причины.
• Тестовый код следует модифицировать гораздо реже, чем код его тестировании.
• Протестированные код могут быть более легко подвергнуты рефакторизации.
• Тесты для модулей, написанных на языке C, все равно должны быть в отдельных модулях, так что почему бы не быть последовательными?
• При изменении стратегии тестирования нет необходимости изменять исходный код.

Повторное использование старого тестового кода

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

По этой причине unittest предоставляет класс FunctionTestCase. Этот подкласс TestCase можно используемый для переноса существующей тестовой функции. Также могут быть предусмотрены функции настройки и разрыва.

При выполнении следующей тестовой функции:

def testSomething():
    something = makeSomething()
    assert something.name is not None
    # ...

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

testcase = unittest.FunctionTestCase(testSomething,
                                     setUp=makeSomethingDB,
                                     tearDown=deleteSomethingDB)

Примечание

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

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

Пропуск тестов и ожидаемых сбоев

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

Unittest поддерживает пропуск отдельных методов тестирования и даже целых классов тестов. Кроме того, он поддерживает маркировку теста как «ожидаемого отказа», теста, который нарушен и завершится неуспешно, но не должен считаться отказом на TestResult.

Пропуск теста - это просто вопрос использования skip() декоратор или одного из его условных вариантов, вызова TestCase.skipTest() в рамках setUp() или метода тестирования или непосредственно подняв SkipTest.

Основной пропуск выглядит так:

class MyTestCase(unittest.TestCase):

    @unittest.skip("demonstrating skipping")
    def test_nothing(self):
        self.fail("shouldn't happen")

    @unittest.skipIf(mylib.__version__ < (1, 3),
                     "not supported in this library version")
    def test_format(self):
        # Тесты, работающие только для определенной версии библиотеки.
        pass

    @unittest.skipUnless(sys.platform.startswith("win"), "requires Windows")
    def test_windows_support(self):
        # тестирующий код для Windows
        pass

    def test_maybe_skipped(self):
        if not external_resource_available():
            self.skipTest("external resource not available")
        # тестовый код, зависящий от внешнего ресурса
        pass

Это результат выполнения приведенного выше примера в подробном режиме:

test_format (__main__.MyTestCase) ... skipped 'not supported in this library version'
test_nothing (__main__.MyTestCase) ... skipped 'demonstrating skipping'
test_maybe_skipped (__main__.MyTestCase) ... skipped 'external resource not available'
test_windows_support (__main__.MyTestCase) ... skipped 'requires Windows'

----------------------------------------------------------------------
Ran 4 tests in 0.005s

OK (skipped=4)

Классы можно пропускать, как и методы:

@unittest.skip("showing class skipping")
class MySkippedTestCase(unittest.TestCase):
    def test_not_run(self):
        pass

TestCase.setUp() также можете пропустить тест. Это полезно, когда ресурс, который необходимо настроить, недоступен.

Ожидаемые сбои используют декоратор expectedFailure().:

class ExpectedFailureTestCase(unittest.TestCase):
    @unittest.expectedFailure
    def test_fail(self):
        self.assertEqual(1, 0, "broken")

Легко прокатывать собственные пропускающие декораторы, делая декоратор, который вызывает skip() на тесте, когда он хочет, чтобы его пропускали. Этот декоратор пропускает тест, если переданный объект не имеет определенного атрибут:

def skipUnlessHasattr(obj, attr):
    if hasattr(obj, attr):
        return lambda func: func
    return unittest.skip("{!r} doesn't have {!r}".format(obj, attr))

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

@unittest.skip(reason)

Безоговорочно пропустите оформленный тест. reason должны описать, почему тест пропускается.

@unittest.skipIf(condition, reason)

Пропустите оформленный тест, если condition истина.

@unittest.skipUnless(condition, reason)

Пропустите оформленный тест, если condition не соответствует действительности.

@unittest.expectedFailure

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

exception unittest.SkipTest(reason)

Это исключение создается для пропуска теста.

Обычно можно использовать TestCase.skipTest() или один из пропускающих декораторов вместо того, чтобы поднимать это напрямую.

Пропущенные тесты не будут иметь setUp() или tearDown() выполняться вокруг них. Пропущенные классы не будут иметь setUpClass() или tearDownClass() запуска. Пропущенные модули не будут иметь setUpModule() или tearDownModule() запуска.

Выделение итераций теста с помощью субтестов

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

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

Например, следующий тест:

class NumbersTest(unittest.TestCase):

    def test_even(self):
        """
        Проверить, что все числа от 0 до 5 являются четными.
        """
        for i in range(0, 6):
            with self.subTest(i=i):
                self.assertEqual(i % 2, 0)

будут получены следующие выходные данные:

======================================================================
FAIL: test_even (__main__.NumbersTest) (i=1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest) (i=3)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

======================================================================
FAIL: test_even (__main__.NumbersTest) (i=5)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

Без использования субтеста выполнение будет остановлено после первого сбоя, и ошибка будет менее простой в диагностике, так как значение i не будет отображаться:

======================================================================
FAIL: test_even (__main__.NumbersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 32, in test_even
    self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

Классы и функции

В этом разделе подробно описывается API unittest.

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

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

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

assertEqual(first, second, msg=None)

Проверить, что first и second равны. Если значения не сравниваются одинаково, тест завершится неуспешно.

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

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

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

assertNotEqual(first, second, msg=None)

Проверить, что first и second не равны. Если значения сравниваются одинаково, тест завершится неуспешно.

assertTrue(expr, msg=None)

assertFalse(expr, msg=None)

Проверить, что expr имеет значение true (или false).

Обратите внимание, что это эквивалентно 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 или str, дающим имя регистратора. По умолчанию используется корневой регистратор, который перехватывает все сообщения, которые не были заблокированы нераспространяющимся потомком регистратора.

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

Если вместо 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: Added under the name assertRegexpMatches.

Изменено в версии 3.2: The method assertRegexpMatches() has been renamed to assertRegex().

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

Добавлено в версии 3.5: The name assertNotRegexpMatches is a deprecated alias for 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)

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

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

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

maxDiff

Этот атрибут управляет максимальной длиной выходных данных diffs с помощью методов утверждения, сообщающих об ошибках diffs. Значение по умолчанию: 80 * 8 символов. Методы утверждения, на которые влияет этот атрибут, являются 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(). При необходимости вызова функций очистки prior 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, а также принимает coroutines в качестве тестовых функций.

Добавлено в версии 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-основанных тестовых фреймворков.

Устаревшие псевдонимы

По историческим причинам некоторые из TestCase методов имели один или несколько псевдонимов, которые теперь устарели. В следующей таблице перечислены правильные имена и устаревшие псевдонимы:

Название метода	Устаревший псевдоним	Устаревший псевдоним
assertEqual()	failUnlessEqual	assertEquals
assertNotEqual()	failIfEqual	assertNotEquals
assertTrue()	failUnless	assert_
assertFalse()	failIf
assertRaises()	failUnlessRaises
assertAlmostEqual()	failUnlessAlmostEqual	assertAlmostEquals
assertNotAlmostEqual()	failIfAlmostEqual	assertNotAlmostEquals
assertRegex()		assertRegexpMatches
assertNotRegex()		assertNotRegexpMatches
assertRaisesRegex()		assertRaisesRegexp

Не рекомендуется, начиная с версии 3.1: Псевдонимы fail*, перечисленные во втором столбце, устарели.

Не рекомендуется, начиная с версии 3.2: Псевдонимы assert*, перечисленные в третьем столбце, устарели.

Не рекомендуется, начиная с версии 3.2: assertRegexpMatches и assertRaisesRegexp переименованы в assertRegex() и assertRaisesRegex().

Не рекомендуется, начиная с версии 3.5: Название assertNotRegexpMatches устарело в пользу assertNotRegex().

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

class unittest.TestSuite(tests=())

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

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

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

addTest(test)

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

addTests(tests)

Добавить все тесты из списка TestCase и TestSuite сущности в этот набор тестов.

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

TestSuite использует следующие методы совместно с TestCase:

run(result)

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

debug()

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

countTestCases()

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

__iter__()

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

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

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

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

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

class unittest.TestLoader

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

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

errors

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

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

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

loadTestsFromTestCase(testCaseClass)

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

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

loadTestsFromModule(module, pattern=None)

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

Примечание

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

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

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

Изменено в версии 3.5: Аргумент по умолчанию без документов и неофициальный аргумент use_load_tests по умолчанию устаревает и игнорируется, хотя он по-прежнему принимается для обратной совместимости. Теперь метод также принимает аргумент ключевой-only 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: Если во время прохождения происходит ImportError или AttributeError name то синтетический тест, который вызывает эту ошибку при запуске, будет возвращенный. Эти ошибки включаются в ошибки, накопленные self.errors.

loadTestsFromNames(names, module=None)

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

getTestCaseNames(testCaseClass)

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

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

Найти все тестовые модули, рекурсивно перейдя в подкаталоги из указанного начального каталога, и возвращает содержащий их объект StartSuite. Будут загружены только тестовые файлы, соответствующие 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 при импорте, записываются как пропуски, а не ошибки. discover работает на пакете пространства имен. Пути сортируются перед импортом так, чтобы порядок выполнения был одинаковым, даже если порядок базовой файловой системы не зависит от имени файла.

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

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

load_tests протокол

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

Модули или пакеты могут настраивать способ загрузки тестов из них во время обычных тестовых запусков или обнаружения тестов путем реализации функции под названием load_tests.

Если тестовый модуль определяет load_tests он будет вызван по TestLoader.loadTestsFromModule() со следующими аргументами:

load_tests(loader, standard_tests, pattern)

где pattern проходит прямо из loadTestsFromModule. Значение по умолчанию - None.

Должна возвращать TestSuite.

loader - это сущность TestLoader, выполняющих загрузку. standard_tests тесты, которые будут загружены из модуля по умолчанию. Обычно модули тестирования хотят только добавлять или удалять тесты из стандартного набора тестов. Третий аргумент - используемый при загрузке пакетов как части обнаружения теста.

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

test_cases = (TestCase1, TestCase2, TestCase3)

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

Если обнаружение запускается в каталоге, содержащем пакет, либо из командной строки, либо путем вызова TestLoader.discover(), то __init__.py пакета будет проверен на load_tests. Если эта функция не существует, обнаружение рекурсирует пакет, как если бы он был просто другим каталогом. В противном случае обнаружение тестов пакета будет оставлено до load_tests, который вызывается со следующими аргументами:

load_tests(loader, standard_tests, pattern)

Это должно возвращает TestSuite, представляющее все тесты из пакета. (standard_tests будет содержать только тесты, собранные из __init__.py.)

Поскольку шаблон передается в load_tests, пакет может продолжать (и потенциально изменять) обнаружение теста. Функция „Ничего не делать“ load_tests для тестового пакета будет выглядеть как:

def load_tests(loader, standard_tests, pattern):
    # каталог верхнего уровня, кэшированный в экземпляре загрузчика
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

Изменено в версии 3.5: Обнаружение больше не проверяет имена пакетов на соответствие шаблона из-за невозможности соответствия имен пакетов шаблону по умолчанию.

Фикстуры класса и модуля

Фикстуры уровня класса и модуля реализованы в TestSuite. Когда набор тестов сталкивается с тестом из нового класса, вызывается tearDownClass() из предыдущего класса (если он есть), за которым следуют setUpClass() из нового класса.

Аналогично, если тест выполняется из модуля, отличного от предыдущего, то выполняется tearDownModule из предыдущего модуля с последующим setUpModule из нового модуля.

После завершения всех тестов выполняются окончательные tearDownClass и tearDownModule.

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

Порядок по умолчанию тестов, созданных загрузчиками тестов с наименьшими значениями, заключается в объединении всех тестов из одних и тех же модулей и классов. Это приведет к вызову setUpClass/ setUpModule (etc) ровно один раз для каждого класса и модуля. При рандомизации порядка, чтобы тесты из различных модулей и классов были смежны друг с другом, эти общие функции фикстуры можно вызвать несколько раз в одном тестовом прогоне.

Общие фикстуры не предназначены для работы с комплектами с нестандартным заказом. По-прежнему существует BaseTestSuite для фреймворков, которые не хотят поддерживать общие фикстуры.

При возникновении каких-либо исключений во время выполнения одной из функций совместно используемых приспособлений тест считается ошибкой. Поскольку соответствующий тест отсутствует сущность для представления ошибки создается объект _ErrorHolder (имеющий тот же интерфейс, что и TestCase). Если вы просто используете стандартный бегун теста unittest, то эта деталь не имеет значения, но если вы фреймворк автор, это может быть актуально.

setUpClass и tearDeyClass

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

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 и tearDaseModule

Они должны быть реализованы в качестве функций:

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.

Обработка сигналов

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

Параметр -c/--catch командной строки unittest, а также параметр catchbreak для unittest.main() обеспечивают более удобную обработку control-C во время тестового запуска. С включенным контролем поведения прерывания control-C позволит завершить текущий выполняемый тест, а затем завершит тестовый запуск и сообщит о всех результатах. Второй control-c поднимает KeyboardInterrupt обычным образом.

Сигнал обработки control-c обработчик пытается оставаться совместимым с код или тестами, устанавливающими собственные signal.SIGINT обработчик. Если unittest обработчик вызывается, но * не является * установленным signal.SIGINT обработчик, т.е. он был заменен тестируемой системой и делегирован ей, то он вызывает обработчик по умолчанию. Это обычно является ожидаемым поведением код, который заменяет установленный обработчик и делегирует его. Для отдельных тестов, которые требуют отключения обработки unittest control-c, можно removeHandler() декоратор используемый.

Для авторов фреймворк существует несколько функций утилит, позволяющих использовать функции управления с в тестовых фреймворков.

unittest.installHandler()

Установить обработчик control-c. При получении signal.SIGINT (обычно в ответ на нажатие пользователем control-c) stop() вызваны все зарегистрированные результаты.

unittest.registerResult(result)

Зарегистрировать объект TestResult для обработки control-c. При регистрации результата сохраняется слабая ссылка на него, поэтому он не препятствует сбору мусора.

Регистрация объекта TestResult не имеет побочных эффектов, если обработка control-c не включена, поэтому тестовые фреймворков могут безоговорочно регистрировать все результаты, которые они создают, независимо от того, включена ли обработка.

unittest.removeResult(result)

unittest.installHandler()

Удаление зарегистрированного результата. После удаления результата :meth:`~TestResult.stop`

больше не будет вызываться для этого объекта результата в ответ на

control-c.

unittest.removeHandler(function=None)

При вызове без аргументов эта функция удаляет обработчик control-c, если он был установлен. Эта функция также может быть используема в качестве декоратора теста для временного удаления обработчика во время выполнения теста:

@unittest.removeHandler
def test_signal_handling(self):
    ...