test — пакет регрессионных тестов для Python

Написание модульных тестов для пакета test

При написании тестов с использованием модуля unittest рекомендуется придерживаться нескольких рекомендаций. Например, имя тестового модуля должно начинаться с test_ и заканчиваться именем проверяемого модуля. Имена тестовых методов в модуле должны начинаться с test_ и заканчиваться описанием того, что проверяет метод. Это необходимо, чтобы драйвер тестирования распознавал методы как тестовые. Кроме того, не следует включать строку документации для метода. Для документирования тестовых методов следует использовать комментарий (например, # Tests function returns only True or False). Это связано с тем, что строки документации выводятся на экран, если они есть, и поэтому не указывается, какой тест выполняется.

Часто используется следующий шаблон:

import unittest
from test import support

class MyTestCase1(unittest.TestCase):

    # Only use setUp() and tearDown() if necessary

    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):
        # Test feature one.
        ... testing code ...

    def test_feature_two(self):
        # Test feature two.
        ... 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, запускаются как тесты. Класс TestFuncAcceptsSequencesMixin в приведённом выше примере не содержит данных и поэтому не может запускаться самостоятельно; следовательно, он не наследует unittest.TestCase.

Запуск тестов с помощью интерфейса командной строки

Благодаря параметру -m пакет test можно запускать как скрипт для выполнения набора регрессионных тестов Python: 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 выполнит все регрессионные тесты.