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