Предпочитаемая структура модульного тестирования Python

До сих пор я использовал встроенный модуль unittest (pyUnit) для модульного тестирования кода Python. Однако для простых случаев это кажется излишним. Будучи производным от xUnit, он выглядит немного тяжелым для динамического характера Python, где я ожидаю меньше писать для достижения тех же эффектов. С другой стороны, он встроен, он заставляет вас писать свои тесты организованным образом и проверяется временем.

Основные альтернативы, которые я видел онлайн:

Какую из структур вы предпочитаете и почему?

Обновление 10.12.2011: с недавним добавлением теста автоматического обнаружения и многих новых функций в unittest (в Python 2.7 и 3.2), IMHO имеет смысл использовать внешнюю библиотеку.

Относительно доктрины: Я не рассматриваю его как единое тестирование. Я определенно не буду использовать его для написания большого набора тестов для значительного приложения. doctest больше подходит для того, чтобы убедиться, что примеры, которые вы предоставляете в документации, работают. Он имеет свое место для этой потребности, но он не является конкурентом для unittest, py.test и других фреймворков.

ОТВЕТЫ

Ответ 1

nose на самом деле не является модульной схемой тестирования. Это тест-бегун и отличный в этом. Он может запускать тесты, созданные с помощью unittest, py.test или doctest.

Мое предпочтение для модульного тестирования - стандартный unittest модуль (также известный как pyUnit). Он похож на другие рамки xUnit и легко связан с людьми без фона python. В Eclipse/PyDev также есть хорошая поддержка

В py.test я нахожу несколько уровней настройки/разрывов очень запутанными. Я также считаю, что это приводит к очень неструктурированным и трудно читаемым модульным тестам.

doctest в порядке для простых вещей, но я считаю, что он очень ограничен и не очень масштабируется для сложного и высокоинтерактивного кода.

Ответ 2

Интересно, что никто еще не ответил, чтобы защитить py.test. В списке рассылки для тестирования в питоне он довольно популярен, например. этот недавний поток "зачем вы используете py.test?" . Наиболее распространенные ответы включали:

  • простая поддержка распределенного тестирования
  • хорошая архитектура плагина
  • более простые утверждения (просто assert x == 42, no assertEqual())
  • funcargs (начиная с версии 2.3 или 2.4, которая несколько отличается от того, что другие тестовые фреймворки называют светильниками)

Ответ 3

Сначала мы начали нашу инфраструктуру автоматизации с помощью unittest и nosetest. Мы подклассифицировали все наши тестовые классы из unittest, поскольку unittest предлагает отличный синтаксис для утверждений. Для фактического запуска тестов мы использовали нос, который был довольно хорош с точки зрения отчетности и указывал, какие тесты необходимо выполнить. Логика генерации тестов также была довольно хорошей - с использованием метода доходности он был прост в использовании. Единственная проблема с генерацией теста носа заключается в том, что тестовый класс не может наследовать от unittest - тогда генерируется тестовое поколение. Здесь могут быть использованы только носовые утверждения.

Мы столкнулись с серьезными проблемами с носом, когда мы хотели распараллелить тестовые прогоны. Чрезвычайно сжатые сообщения привели к тому, что тесты проводились параллельно. Кроме того, если вы создаете определенные ресурсы в методах настройки, то и распараллеливание терпит неудачу с странными ошибками. Казалось очень сложным использовать нос, чтобы распараллелить тестовые прогоны - мы почти все пытались. Затем, наконец, один из наших членов команды ударил по py.test. В течение очень короткого времени он смог внести необходимые изменения в набор из 30 тестов, чтобы запустить их параллельно. Он начал бежать, и к его удивлению пробег прошел в записи за 15 минут от предыдущих 75 минут, которые он использовал. Он смог успешно провести все 30 тестов параллельно с меньшим количеством усилий и хлопот. Синтаксис был также прост, и отчетность была превосходной - далеко превосходила отчетность носовой рамки.

Итак, я бы сказал, что выигрышная комбинация - py.test с unittest.

Ответ 4

Я использую только стандартный unittest. Не знаете, как вы могли бы эффективно писать тесты с другим стилем - возможно, каждый тест в функции, но тогда как бы вы справились с настройкой/отключением?

Ответ 5

nose2 вытеснил нос и поддерживает параметризованные тесты, что означает, что вы можете запускать те же утверждения с разными параметрами. Это позволяет вам покрывать больше сценариев с гораздо меньшим количеством кода.

Ответ 6

unittest.TestCase - это класс. Не стесняйтесь подклассифицировать его своими дополнительными функциями, которые позволят вам "писать меньше для достижения тех же эффектов".

Ответ 7

Я согласен, что одна из самых приятных особенностей носа - плагиновая система. Например, я начал изучать Python, когда запускался Google App Engine, и появился плагин Nose для поддержки GAE почти сразу. Таким образом, нос с плагинами помог мне начать с тестовой разработки с новой платформы, такой как GAE с самого начала. Плагин покрытия был там, когда я был готов к этому.

Ответ 8

Одной из самых приятных особенностей носа является его плагиновая система: например, плагин охвата показывает, сколько вашего кода покрыто unittests. После написания большого количества unittests часто шокирует, чтобы узнать, сколько вашего кода не покрыто....

Ответ 9

Всегда doctest, если вы хотите, чтобы ваши тесты устройств были близки к коду.

НТН

Ответ 10

Я думаю, что это вопрос выбора действительно. Я использовал все основные рамки тестирования, это сводится к тому, что, по вашему мнению, делает работу с меньшей кодировкой. Тем не менее, я предпочитаю доктрину.