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, выполняются как тесты. Класс TestFuncAcceptsSequencesMixin в приведенном выше примере не имеет данных и поэтому не может выполняться сам по себе, следовательно, он не наследуется от 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 выполнит все регрессионные тесты.