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

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

Примечание

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

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

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

См. также

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

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

Для тестов, использующих модуль unittest, рекомендуется следовать нескольким правилам. Одно из них – называть модуль тестов, начиная его имя с test_ и заканчивая названием тестируемого модуля. Методы тестов в модуле тестирования должны начинаться с test_ и заканчиваться описанием того, что метод тестирует. Это необходимо, чтобы тестовый драйвер распознавал методы как тестовые. Кроме того, не следует включать строку документации для метода. Вместо этого следует использовать комментарий (например, # Tests function returns only True or 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 ...

def test_main():
    support.run_unittest(MyTestCase1,
                         MyTestCase2,
                         ... list other tests ...
                         )

if __name__ == '__main__':
    test_main()

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

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

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

    func = mySuperWhammyFunction

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

class AcceptLists(TestFuncAcceptsSequences):
    arg = [1, 2, 3]

class AcceptStrings(TestFuncAcceptsSequences):
    arg = 'abc'

class AcceptTuples(TestFuncAcceptsSequences):
    arg = (1, 2, 3)
```

См. также

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

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

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

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

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

Изменено в версии 2.7.14: Пакет test можно запускать как скрипт: python -m test. Это работает так же, как запуск модуля test.regrtest.

25.6. `test.support` – Вспомогательные функции для тестов¶test.support – Utility functions for tests

Примечание

Модуль test.test_support был переименован в test.support в Python 3.x и 2.7.14. Имя test.test_support сохранено как псевдоним в 2.7.

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

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

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.have_unicode¶: True если доступна поддержка Unicode.

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

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

test.support.TEST_HTTP_URL¶: Определяет URL выделенного HTTP-сервера для сетевых тестов.

Модуль 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])¶: Возбуждает ResourceDenied, если resource недоступен. msg – это аргумент для ResourceDenied, если он возбуждается. Всегда возвращает True, если вызвана из функции, чей __name__ равен '__main__'. Используется при выполнении тестов с помощью test.regrtest.

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

test.support.run_unittest(*classes)¶

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

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

def test_main():
    support.run_unittest(__name__)

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

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

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

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

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

test.support.check_py3k_warnings(*filters, quiet=False)¶

Аналогично check_warnings(), но для предупреждений совместимости с Python 3. Если sys.py3kwarning == 1, проверяется, было ли предупреждение фактически вызвано. Если sys.py3kwarning == 0, проверяется, что предупреждение не было вызвано. Функция принимает кортежи из двух элементов вида ("message regexp", WarningCategory) в качестве позиционных аргументов. Когда необязательный именованный аргумент quiet равен True, она не считает ошибкой, если фильтр не поймал ничего. Без аргументов по умолчанию она равна:

check_py3k_warnings(("", DeprecationWarning), quiet=False)

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

test.support.captured_stdout()¶

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

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

with captured_stdout() as s:
    print "hello"
assert s.getvalue() == "hello\n"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EnvironmentVarGuard.unset(envvar)¶: Временно удаляет переменную окружения envvar.

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

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

25.5. test – Пакет регрессионных тестов для Python¶test – Regression tests package for Python

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

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

25.6. test.support – Вспомогательные функции для тестов¶test.support – Utility functions for tests

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

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

25.6. `test.support` – Вспомогательные функции для тестов¶test.support – Utility functions for tests