Предпочитаемая структура модульного тестирования 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
Я думаю, что это вопрос выбора действительно. Я использовал все основные рамки тестирования, это сводится к тому, что, по вашему мнению, делает работу с меньшей кодировкой.
Тем не менее, я предпочитаю доктрину.