нос против pytest - какие (субъективные) различия должны побудить меня выбрать? [закрыто]


85

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

И нос, и pytest поддерживают такую ​​вещь, потому что они поддерживают приспособления на многих уровнях детализации, поэтому мы планируем переключиться на нос или pytest. Обе эти библиотеки также будут поддерживать тесты «тегирования» и запускать только эти помеченные подмножества, что мы также хотели бы сделать.

Я немного просмотрел документацию и по носу, и по pytest, и, насколько я могу судить, большая часть этих библиотек по существу поддерживает одни и те же функции, за исключением того, что они могут называться по-другому или требовать немного другого синтаксиса. Кроме того, я заметил некоторые небольшие различия в доступных плагинах (в носу есть поддержка многопроцессорности, например, в pytest нет).

Кажется, дьявол кроется в деталях, что означает (по крайней мере, часто) в личном вкусе, и нам лучше выбрать библиотеку, которая лучше всего соответствует нашему личному вкусу.

Так что я бы попросил субъективного аргументации, почему я должен использовать нос или pytest, чтобы выбрать комбинацию библиотеки / сообщества, которая наилучшим образом соответствует нашим потребностям.


Только что заметил, что более или менее тот же вопрос был задан и здесь - но это было пять лет назад, так что я все еще думаю, что повторная постановка вопроса имеет смысл
Якоб ван Вифлеем

9
pytestподдерживает многопроцессорную поддержку через плагин pytest-xdist .
Бруно Оливейра

2
Кроме того, диспетчеры контекста - это просто объекты Python, и вы можете вызывать как manager.__enter__()в своем TestCase.setUp(), так и manager.__exit__()в своем tearDown().
rescdsk

Ответы:


80

Раньше я использовал Nose, потому что он использовался по умолчанию в Pylons. Мне это совсем не понравилось. У него были заусеницы конфигурации в нескольких местах, практически все, казалось, было сделано с помощью недокументированного плагина, что сделало все еще более косвенным и запутанным, и поскольку он по умолчанию выполнял тесты unittest, он регулярно прерывал трассировку Unicode, скрывая источники ошибок.

Я был очень доволен py.test последние пару лет. Будучи в состоянии просто написать тест с assertиз коробки заставляет меня терпеть не писать тесты пути меньше, и взлом , что мне нужно на вершину ядра было довольно легко. Вместо фиксированного интерфейса плагина у него просто куча крючков и довольно понятный исходный код, если вам нужно будет копать дальше. Я даже написал адаптер для запуска тестов Testify под py.test, и у меня было больше проблем с Testify, чем с py.test.

Тем не менее, я слышал, что в Носе есть плагины для бесклассовых тестов и самоанализа в настоящее время, так что вы, вероятно, справитесь с любым из них. Я все еще чувствую, что могу взяться за дело с py.test, и я могу понять, что происходит, когда он ломается.


2
Некоторые проблемы со скрытием трассировок были исправлены примерно на уровне 0.11, много лет назад. Поскольку порт Python 3, я ожидаю, что любые трассировки Unicode будут менее частыми (хотя лично я думаю, что столкнулся с проблемой Unicode с носом только один раз, которая возникла при объединении ее с некоторым базовым классом тестового примера, который выполнил какой-то «трюк», который не работал) Это действительно имеет смысл - так что это оказалось не вина носа). Я подозреваю, что на самом деле у обоих инструментов с годами были
неровности

как насчет недавней части документации. Я также не понимаю, использовать ли тесты на нос или на py.test. оба кажутся одинаково хорошими, но, как я читал, в наши дни большинство людей используют носовые тесты. В чем может быть причина того, что у py.tests есть лучший набор доступных многопроцессорных библиотек?
proprius

1
@prectus, может быть, сначала были тесты на нос. некоторые фреймворки добавили его поддержку, проекты, использующие эти фреймворки, использовали его по умолчанию, и он распространился. Кроме того, хотя py.test может запускать тесты и тесты unittest, его обычный стиль не привязан к классам, поэтому перенос на py.test может показаться сложным.
Eevee

4
Я начал читать часть документации pytest и понял, что для целей многопроцессорности, а также с точки зрения обучения новичку, pytest - лучший выбор.
proprius
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.