Содержание страницы

26.7. `test` – пакет регрессионного тестирования для Python¶test – Regression tests package for Python

Примечание

Пакет test предназначен только для внутреннего использования Python. Он документирован для пользы основных разработчиков Python. Любое использование этого пакета за пределами стандартной библиотеки Python не рекомендуется, так как упомянутый здесь код может быть изменён или удалён без предупреждения между выпусками Python.

Пакет test содержит все регрессионные тесты для Python, а также модули test.support и test.regrtest. test.support используется для улучшения тестов, а test.regrtest управляет набором тестов.

Каждый модуль в пакете test, имя которого начинается с test_, является набором тестов для конкретного модуля или функции. Все новые тесты следует писать с использованием модуля unittest или doctest. Некоторые старые тесты написаны в «традиционном» стиле тестирования, который сравнивает вывод, напечатанный в sys.stdout; такой стиль тестов считается устаревшим.

См. также

Модуль unittest: Написание регрессионных тестов PyUnit.
Модуль doctest: Тесты, встроенные в строки документации.

26.7.1. Написание модульных тестов для пакета `test`¶Writing Unit Tests for the test package

Рекомендуется, чтобы тесты, использующие модуль unittest, следовали нескольким рекомендациям. Одна из них – называть тестовый модуль, начиная его с test_ и заканчивая именем тестируемого модуля. Методы тестирования в тестовом модуле должны начинаться с test_ и заканчиваться описанием того, что тестирует метод. Это необходимо, чтобы драйвер тестов распознавал методы как тестовые. Кроме того, не следует включать строку документации для метода. Вместо этого следует использовать комментарий (например, # Тестирует функция возвращает только True или False) для документирования тестовых методов. Это сделано потому, что строки документации выводятся на печать, если они существуют, и, таким образом, не указывается, какой именно тест выполняется.

Часто используется стандартная заготовка:

import unittest
from test import support

class MyTestCase1(unittest.TestCase):

    # Используйте setUp() и tearDown() только при необходимости

    def setUp(self):
        ... code to execute in preparation for tests ...

    def tearDown(self):
        ... code to execute to clean up after tests ...

    def test_feature_one(self):
        # Тест первой возможности.
        ... testing code ...

    def test_feature_two(self):
        # Тест второй возможности.
        ... testing code ...

    ... more test methods ...

class MyTestCase2(unittest.TestCase):
    ... same structure as MyTestCase1 ...

... more test classes ...

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

Этот шаблон кода позволяет запускать набор тестов с помощью test.regrtest, как отдельный скрипт, поддерживающий CLI unittest, или через CLI python -m unittest.

Цель регрессионного тестирования – попытаться сломать код. Это приводит к нескольким правилам, которым следует следовать:

Набор тестов должен задействовать все классы, функции и константы. Это включает не только внешний API, который будет представлен внешнему миру, но и «приватный» код.
Предпочтительно тестирование методом белого ящика (анализ тестируемого кода при написании тестов). Тестирование методом чёрного ящика (тестирование только опубликованного пользовательского интерфейса) недостаточно для проверки всех граничных и крайних случаев.
Убедитесь, что все возможные значения протестированы, включая недопустимые. Это гарантирует, что не только все допустимые значения принимаются, но и неправильные значения обрабатываются корректно.
Исчерпайте как можно больше путей выполнения кода. Тестируйте места ветвления и соответственно подбирайте входные данные, чтобы гарантировать, что проходит как можно больше различных путей.
Добавляйте явные тесты для любых ошибок, обнаруженных в тестируемом коде. Это гарантирует, что ошибка не возникнет снова, если код будет изменён в будущем.
Убедитесь, что после тестов выполнена очистка (например, закрыты и удалены все временные файлы).
Если тест зависит от конкретного условия операционной системы, то проверьте, что условие уже выполняется, прежде чем запускать тест.
Импортируйте как можно меньше модулей и делайте это как можно раньше. Это минимизирует внешние зависимости тестов, а также уменьшает возможные аномальные поведения из-за побочных эффектов импорта модуля.
Старайтесь максимально повторно использовать код. Иногда тесты могут различаться такой мелочью, как тип используемых входных данных. Минимизируйте дублирование кода, создавая подкласс базового тестового класса, который определяет входные данные:
```
class TestFuncAcceptsSequencesMixin:

    func = mySuperWhammyFunction

    def test_func(self):
        self.func(self.arg)

class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
    arg = [1, 2, 3]

class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase):
    arg = 'abc'

class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):
    arg = (1, 2, 3)
```
При использовании этого шаблона помните, что все классы, наследующие от unittest.TestCase, выполняются как тесты. Класс Mixin в примере выше не содержит никаких данных и поэтому не может быть запущен сам по себе, следовательно, он не наследует от unittest.TestCase.

См. также

Разработка через тестирование: Книга Кента Бека о написании тестов до кода.

26.7.2. Запуск тестов с помощью интерфейса командной строки¶Running tests using the command-line interface

Пакет test можно запускать как скрипт для управления набором регрессионных тестов Python благодаря опции -m: python -m test. Под капотом он использует test.regrtest; вызов python -m test.regrtest, использовавшийся в предыдущих версиях Python, всё ещё работает. Запуск скрипта самостоятельно автоматически запускает все регрессионные тесты в пакете test. Это делается путём поиска всех модулей в пакете, имена которых начинаются с test_, их импорта и выполнения функции test_main(), если она присутствует, или загрузки тестов через unittest.TestLoader.loadTestsFromModule, если test_main не существует. Имена тестов для выполнения также могут быть переданы скрипту. Указание одного регрессионного теста (python -m test test_spam) минимизирует вывод и покажет только, прошёл тест или провалился.

Запуск test напрямую позволяет задать, какие ресурсы доступны для использования тестам. Это делается с помощью опции командной строки -u. Указание all в качестве значения опции -u включает все возможные ресурсы: python -m test -uall. Если нужны все ресурсы, кроме одного (более частый случай), после all можно перечислить через запятую ресурсы, которые не нужны. Команда python -m test -uall,-audio,-largefile запустит test со всеми ресурсами, кроме audio и largefile. Для списка всех ресурсов и дополнительных опций командной строки выполните python -m test -h.

Некоторые другие способы выполнения регрессионных тестов зависят от платформы, на которой они выполняются. В Unix можно выполнить make test в корневом каталоге, где был собран Python. В Windows выполнение rt.bat из каталога PCBuild запустит все регрессионные тесты.

26.8. `test.support` – утилиты для набора тестов Python¶test.support – Utilities for the Python test suite

Модуль test.support обеспечивает поддержку набора регрессионных тестов Python.

Примечание

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

В этом модуле определены следующие исключения:

exception test.support.TestFailed¶: Исключение, возбуждаемое при сбое теста. Это устарело в пользу тестов на основе unittest и методов утверждений unittest.TestCase.

exception test.support.ResourceDenied¶: Подкласс unittest.SkipTest. Возбуждается, когда ресурс (например, сетевое соединение) недоступен. Возбуждается функцией requires().

Модуль test.support определяет следующие константы:

test.support.verbose¶: True, когда включён подробный вывод. Следует проверять, когда требуется более подробная информация о выполняющемся тесте. verbose устанавливается test.regrtest.

test.support.is_jython¶: True, если работающий интерпретатор – Jython.

test.support.TESTFN¶: Устанавливается в имя, безопасное для использования в качестве имени временного файла. Любой созданный временный файл должен быть закрыт и удалён.

Модуль test.support определяет следующие функции:

test.support.forget(module_name)¶: Удаляет модуль с именем module_name из sys.modules и удаляет все скомпилированные в байт-код файлы этого модуля.

test.support.is_resource_enabled(resource)¶: Возвращает True, если resource включён и доступен. Список доступных ресурсов задаётся только тогда, когда test.regrtest выполняет тесты.

test.support.requires(resource, msg=None)¶: Вызывает исключение ResourceDenied, если resource недоступен. msg – аргумент для ResourceDenied, если исключение выбрасывается. Всегда возвращает True, если вызвана из функции, чьё __name__ равно '__main__'. Используется, когда тесты выполняются test.regrtest.

test.support.findfile(filename, subdir=None)¶: Возвращает путь к файлу с именем filename. Если совпадений не найдено, возвращается filename. Это не считается ошибкой, так как оно может быть путём к файлу.

Установка subdir задаёт относительный путь для поиска файла, а не прямой поиск в каталогах пути.

test.support.run_unittest(*classes)¶

Выполняет подклассы unittest.TestCase, переданные в функцию. Функция просматривает классы в поисках методов, начинающихся с префикса test_, и выполняет тесты по отдельности.

Также допускается передача строк в качестве параметров; они должны быть ключами в sys.modules. Каждый соответствующий модуль будет просканирован с помощью unittest.TestLoader.loadTestsFromModule(). Обычно это встречается в следующей функции test_main():

def test_main():
    support.run_unittest(__name__)

Это запустит все тесты, определенные в указанном модуле.

test.support.run_doctest(module, verbosity=None)¶

Запускает doctest.testmod() для указанного module. Возвращает (failure_count, test_count).

Если verbosity равно None, doctest.testmod() выполняется с подробностью, установленной в verbose. В противном случае выполняется с подробностью, установленной в None.

test.support.check_warnings(*filters, quiet=True)¶

Удобная обёртка для warnings.catch_warnings(), упрощающая проверку того, что предупреждение было правильно вызвано. Она примерно эквивалентна вызову warnings.catch_warnings(record=True) с warnings.simplefilter(), установленным в always, и возможностью автоматически проверять записанные результаты.

check_warnings принимает кортежи из 2 элементов вида ("message regexp", WarningCategory) в качестве позиционных аргументов. Если указан один или несколько filters, или если необязательный ключевой аргумент quiet равен False, выполняется проверка, что предупреждения соответствуют ожиданиям: каждый указанный фильтр должен совпадать хотя бы с одним из предупреждений, вызванных вложенным кодом, иначе тест завершается ошибкой; также, если возникают предупреждения, не совпадающие ни с одним из указанных фильтров, тест завершается ошибкой. Чтобы отключить первую из этих проверок, установите quiet в True.

Если аргументы не указаны, по умолчанию используется:

check_warnings(("", Warning), quiet=True)

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

При входе в контекстный менеджер возвращается экземпляр WarningRecorder. Лежащий в основе список предупреждений из catch_warnings() доступен через атрибут warnings объекта recorder. Для удобства атрибуты объекта, представляющего последнее предупреждение, также можно получить напрямую через объект recorder (см. пример ниже). Если ни одного предупреждения не было вызвано, то любой из атрибутов, которые обычно ожидаются у объекта, представляющего предупреждение, вернёт None.

Объект recorder также имеет метод reset(), который очищает список предупреждений.

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

with check_warnings(("assertion is always true", SyntaxWarning),
                    ("", UserWarning)):
    exec('assert(False, "Hey!")')
    warnings.warn(UserWarning("Hide me!"))

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

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

with check_warnings(quiet=True) as w:
    warnings.warn("foo")
    assert str(w.args[0]) == "foo"
    warnings.warn("bar")
    assert str(w.args[0]) == "bar"
    assert str(w.warnings[0].args[0]) == "foo"
    assert str(w.warnings[1].args[0]) == "bar"
    w.reset()
    assert len(w.warnings) == 0

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

Изменено в версии 3.2: Новые необязательные аргументы filters и quiet.

test.support.captured_stdin()¶

test.support.captured_stdout()¶

test.support.captured_stderr()¶

Контекстный менеджер, который временно заменяет указанный поток объектом io.StringIO.

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

with captured_stdout() as stdout, captured_stderr() as stderr:
    print("hello")
    print("error", file=sys.stderr)
assert stdout.getvalue() == "hello\n"
assert stderr.getvalue() == "error\n"

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

with captured_stdin() as stdin:
    stdin.write('hello\n')
    stdin.seek(0)
    # вызвать тестовый код, который читает из sys.stdin
    captured = input()
self.assertEqual(captured, "hello")

test.support.temp_dir(path=None, quiet=False)¶

Менеджер контекста, который создаёт временную директорию по path и возвращает эту директорию.

Если path равен None, временный каталог создаётся с помощью tempfile.mkdtemp(). Если quiet равно False, контекстный менеджер вызывает исключение при ошибке. В противном случае, если path указан и не может быть создан, выдаётся только предупреждение.

test.support.change_cwd(path, quiet=False)¶

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

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

test.support.temp_cwd(name='tempcwd', quiet=False)¶

Менеджер контекста, который временно создаёт новую директорию и изменяет текущую рабочую директорию (CWD).

Контекстный менеджер создаёт временный каталог в текущем каталоге с именем name, а затем временно изменяет текущий рабочий каталог. Если name равно None, временный каталог создаётся с помощью tempfile.mkdtemp().

Если quiet равно False и невозможно создать или изменить текущий рабочий каталог (CWD), вызывается ошибка. В противном случае выдаётся только предупреждение и используется исходный CWD.

test.support.temp_umask(umask)¶: Менеджер контекста, который временно устанавливает umask процесса.

test.support.can_symlink()¶: Возвращает True, если ОС поддерживает символические ссылки, иначе False.

@test.support.skip_unless_symlink¶: Декоратор для запуска тестов, требующих поддержки символических ссылок.

@test.support.anticipate_failure(condition)¶: Декоратор для условной пометки тестов с помощью unittest.expectedFailure(). Любое использование этого декоратора должно сопровождаться комментарием с указанием соответствующего тикета в системе отслеживания ошибок.

@test.support.run_with_locale(catstr, *locales)¶: Декоратор для запуска функции в другой локали с корректным сбросом локали после завершения. Параметр catstr – это категория локали в виде строки (например, "LC_ALL"). Переданные локали будут перебираться последовательно, и будет использована первая подходящая локаль.

test.support.make_bad_fd()¶: Создаёт некорректный файловый дескриптор, открывая и закрывая временный файл, и возвращая его дескриптор.

test.support.import_module(name, deprecated=False)¶

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

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

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

test.support.import_fresh_module(name, fresh=(), blocked=(), deprecated=False)¶

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

Параметр fresh – это итерируемая последовательность дополнительных имен модулей, которые также удаляются из кеша sys.modules перед выполнением импорта.

Параметр blocked – это итерируемая последовательность имен модулей, которые заменяются на None в кеше модулей во время импорта, чтобы попытки их импорта вызывали исключение ImportError.

Указанный модуль и все модули, перечисленные в параметрах fresh и blocked, сохраняются до начала импорта, а затем повторно вставляются в sys.modules после завершения свежего импорта.

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

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

Пример использования:

# Получение копий модуля warnings для тестирования без влияния на
# версию, используемую остальной частью тестового набора. Одна копия использует
# реализацию на C, другая принудительно использует запасную реализацию на чистом
# реализация
py_warnings = import_fresh_module('warnings', blocked=['_warnings'])
c_warnings = import_fresh_module('warnings', fresh=['_warnings'])

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

test.support.bind_port(sock, host=HOST)¶

Привязывает сокет к свободному порту и возвращает номер порта. Для обеспечения использования непривязанного порта полагается на эфемерные порты. Это важно, так как множество тестов могут выполняться одновременно, особенно в среде buildbot. Этот метод генерирует исключение, если sock.family равно AF_INET, а sock.type равно SOCK_STREAM, и на сокете установлен SO_REUSEADDR или SO_REUSEPORT. Тесты никогда не должны устанавливать эти параметры сокета для сокетов TCP/IP. Единственный случай для их установки – тестирование многоадресной рассылки (multicasting) через несколько UDP-сокетов.

Кроме того, если доступен параметр сокета SO_EXCLUSIVEADDRUSE (например, в Windows), он будет установлен на сокете. Это предотвратит привязку любого другого процесса к нашему хосту/порту на время выполнения теста.

test.support.find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM)¶

Возвращает неиспользуемый порт, который должен подходить для привязки. Это достигается созданием временного сокета с тем же семейством и типом, что и параметр sock (по умолчанию AF_INET, SOCK_STREAM), и его привязкой к указанному адресу хоста (по умолчанию 0.0.0.0) с портом, установленным в 0, запрашивая у ОС неиспользуемый эфемерный порт. Затем временный сокет закрывается и удаляется, а эфемерный порт возвращается.

Для любых тестов, где серверный сокет необходимо привязать к определенному порту на время выполнения теста, следует использовать либо этот метод, либо bind_port(). Какой из них выбрать, зависит от того, создает ли вызывающий код сокет Python или же неиспользуемый порт нужно указать в конструкторе или передать внешней программе (например, аргумент -accept для режима s_server в openssl). Всегда предпочитайте bind_port() вместо find_unused_port(), где это возможно. Использование жестко заданного порта не рекомендуется, так как это может сделать невозможным одновременный запуск нескольких экземпляров теста, что является проблемой для сборочных ботов.

test.support.load_package_tests(pkg_dir, loader, standard_tests, pattern)¶

Общая реализация протокола unittest load_tests для использования в тестовых пакетах. Параметр pkg_dir – это корневой каталог пакета; loader, standard_tests и pattern – аргументы, ожидаемые функцией load_tests. В простых случаях файл __init__.py тестового пакета может быть следующим:

import os
from test.support import load_package_tests

def load_tests(*args):
    return load_package_tests(os.path.dirname(__file__), *args)

Модуль test.support определяет следующие классы:

class test.support.TransientResource(exc, **kwargs)¶: Экземпляры представляют собой менеджер контекста, который генерирует исключение ResourceDenied, если возникает указанный тип исключения. Все именованные аргументы обрабатываются как пары атрибут/значение для сравнения с любым исключением, возникшим внутри блока with. Исключение ResourceDenied возбуждается только в том случае, если все пары правильно совпадают с атрибутами исключения.

class test.support.EnvironmentVarGuard¶: Класс, используемый для временной установки или сброса переменных окружения. Экземпляры можно использовать как менеджер контекста; они имеют полноценный интерфейс словаря для запроса/изменения базового os.environ. После выхода из менеджера контекста все изменения переменных окружения, сделанные через этот экземпляр, будут отменены.

Изменено в версии 3.1: Добавлен интерфейс словаря.

EnvironmentVarGuard.set(envvar, value)¶: Временно устанавливает переменную окружения envvar в значение value.

EnvironmentVarGuard.unset(envvar)¶: Временно сбрасывает переменную окружения envvar.

class test.support.SuppressCrashReport¶

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

В Windows отключает диалоги отчётов об ошибках Windows с помощью SetErrorMode.

На UNIX resource.setrlimit() используется для установки мягкого ограничения resource.RLIMIT_CORE в 0, чтобы предотвратить создание файлов daмпов памяти.

На обеих платформах предыдущее значение восстанавливается с помощью __exit__().

class test.support.WarningsRecorder¶: Класс, используемый для записи предупреждений в модульных тестах. Дополнительные сведения см. в описании check_warnings() выше.

26.7. test – пакет регрессионного тестирования для Python¶test – Regression tests package for Python

26.7.1. Написание модульных тестов для пакета test¶Writing Unit Tests for the test package

26.7.2. Запуск тестов с помощью интерфейса командной строки¶Running tests using the command-line interface

26.8. test.support – утилиты для набора тестов Python¶test.support – Utilities for the Python test suite

26.7. `test` – пакет регрессионного тестирования для Python¶test – Regression tests package for Python

26.7.1. Написание модульных тестов для пакета `test`¶Writing Unit Tests for the test package

26.8. `test.support` – утилиты для набора тестов Python¶test.support – Utilities for the Python test suite