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