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

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

Пакет 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 запустит все регрессионные тесты.