Практика BDD с Python
Какие самые продвинутые фреймворки и инструменты доступны для Python для практики разработки, основанной на поведении? Было бы здорово найти такие инструменты, как rspec и mocha для ruby.
Только на SO быть высокоинформативным равно «неконструктивным».
Ответы 10
Я, вероятно, полностью упускаю суть, но что я сохранил из оригинальная бумага BDD, так это то, что BDD был просто переупакован TDD, чтобы подчеркнуть некоторые лучшие практики.
Если моя интерпретация верна, вы можете получить структуру BDD, просто переименовав методы в любой реализации xUnit. Так что просто продолжайте и используйте стандартную библиотеку модульный тест.
Обновлено: быстрый Google обнаружил модуль Поведение в Сырная лавка. Далее поиск для BDD там больше ничего не нашел.
TDD действительно революционизирует практику в совершенно ином масштабе, чем BDD. Тем не менее, я оценил способ написания тестовых файлов в стиле BDD.
BDD запустился на уровне юнитов, это правда. Он довольно быстро разросся, чтобы охватить поведение на системном уровне, где контексты, события и результаты выигрывают от немного большей возможности повторного использования - отсюда и распространение инструментов для поддержки как этого, так и сценариев на естественном языке, взятых из бесед с нетехническими заинтересованными сторонами. С тех пор, как был задан этот вопрос, мы подняли BDD до уровня видения проекта, используя внедрение функций, с таким же упором на обнаружение через диалог и язык предметной области. По-прежнему ничего нового под солнцем.
Мне нравится этот разговор о bdd youtube.com/watch?v=pherUEzdJow. Я показал хороший способ написать спецификации и использовать их в качестве тестов.
Ян Бикинг рекомендует использовать доктест для проектирования, управляемого поведением:
Лично я предпочитаю использовать нос и макет пустого пространства в стиле дизайна, ориентированном на поведение. В частности, спецификация плагин для носа отлично подходит для BDD.
Эндрю Беннеттс недавно написал пару постов о том, почему, по его мнению, злоупотребляют doctest. andrew.puzzling.org/diary/2008/October/23/narrative-testsandrew.puzzling.org/diary/2008/October/24/more-doctest-probl ems
Я думаю, что на самом деле doctest больше соответствует философии BDD, когда вы относитесь к нему так, как предполагалось: вы начинаете писать о программном обеспечении, а затем перемежаете это примерами, которые также образуют тесты. Его также называют «разработкой, управляемой документами» - суть в том, чтобы сосредоточиться на внешне описываемой функциональности, а не на внутренних единицах работы. Я считаю, что традиция xUnit является ужасна в этом.
Проект Pyccuracy - это попытка предоставить предметно-ориентированный язык для BDD на Python.
В отличие от doctest, который работает на уровне API, он кодирует операции более высокого уровня, такие как загрузка веб-страницы и отправка формы. Я не использовал его, но он выглядит многообещающим, если это то, что вы ищете.
Мне очень нравится Pyccuracy. В настоящее время я реализую это в проекте среднего размера.
Я был бы заинтересован в любом недавнем сравнении Pyccuracy и Lettuce, которым можно поделиться.
Возможно, включите Freshen (ссылка на ответ выше) в сравнение.
Уже спрашивали здесь: quora.com/…
Салат - это инструмент для Python, похожий на огурец: http://lettuce.it/
Вы можете скачать исходный код на github.com/gabrielfalcao/lettuce
Пользователи Windows, рассматривающие салат-латук, должны знать, на момент написания статьи, поддержка этой ОС не является простой задачей.
Любые пользователи, намеревающиеся использовать салат с django, должны знать, что по умолчанию он использует вашу базу данных дефолт для тестирования. Этот интересный выбор дизайна стоил мне одной производственной базы данных
Есть несколько альтернатив салату-латук, например, Behave; вот сообщение в блоге, сравнивающее их и пропагандирующее поведение.
Спасибо @seafangs - Behave выглядит более управляемым для больших проектов, чем Lettuce.
Если вы используете django, сэкономьте время на использовании Lettuce, текущая версия 2.19 не работает с последней версией django.
Я рекомендую вам использовать набор инструментов, разработанный в помощь программистам в практике BDD и TDD. Этот набор инструментов состоит из: пикики, specloud, Ludibrio и должен-dsl.
Должен-DSL даст вам ожидания, подобные RSpec. Все, что вы можете делать с API ожидания RSpec, делает и should-dsl. Вы можете взять последняя версия от Github.
SpecLoud помогает запускать юнит-тесты, подобные BDD. Вы можете установить его, выполнив
pip install specloud
Ludibrio - это библиотека для тестовых двойников (Mocks, Stubs и Dummies). Установите его через
pip install ludibrio
А PyCukes - это основной инструмент для BDD. Он запустит сценарии и т. д. Опять же,
pip install pycukes
Для получения дополнительной информации прочтите документацию по инструментам на PyPi.
Нашел этот полезный документ, ища подробности вашего ответа: arxiv.org/pdf/1007.1722
Мне нравится should-dsl. Я рассматривал DSL для python BDD - их несколько, но этот кажется довольно выразительным.
Я не могу найти никакой информации о фреймворке BDD под названием Pyramid. Ссылка, указанная в документе, связанном с @phaedrus, ведет на сомнительно выглядящий сайт, который не имеет ничего общего с тестированием, а поиск в Google указывает на Пирамида, веб-фреймворк. Кто-нибудь может предоставить актуальную ссылку?
Я предпочитаю DSL утверждения Конечно.
@ BjörnPollex, название Pyramid не могло использоваться создателями этих инструментов из-за Pyramid Web Framework. Теперь это всего лишь отдельные инструменты.
Попробуйте особи. Две мои основные цели при создании этого проекта - сделать тесты легко читаемыми и постоянно запускаемыми во время разработки.
Код теста:
from pyspecs import given, when, then, and_, the, this
with given.two_operands:
a = 2
b = 3
with when.supplied_to_the_add_function:
total = a + b
with then.the_total_should_be_mathmatically_correct:
the(total).should.equal(5)
with and_.the_total_should_be_greater_than_either_operand:
the(total).should.be_greater_than(a)
the(total).should.be_greater_than(b)
with when.supplied_to_the_subtract_function:
difference = b - a
with then.the_difference_should_be_mathmatically_correct:
the(difference).should.equal(1)
Консольный вывод:
# run_pyspecs.py
| • given two operands
| • when supplied to the add function
| • then the total should be mathmatically correct
| • and the total should be greater than either operand
| • when supplied to the subtract function
| • then the difference should be mathmatically correct
(ok) 6 passed (6 steps, 1 scenarios in 0.0002 seconds)
Я очень рекомендую вести себя.
В поисках клона Cucumber для Python я начал использовать салат, но обнаружил, что это довольно неуклюжая копия. Очень непифонично.
Затем я обнаружил, что ведешь себя, и был очень доволен этим.
Я переключился на поведение с салата, когда его поведение по умолчанию - использование базы данных по умолчанию для тестирования в проекте django стоило мне производственной базы данных на живом сервере: Фреймворк тестирования django github.com/rwillmer/django-behave
Я чувствую вашу боль, а также рад видеть, что ваши страдания способствовали процветанию экосистемы django. ;-)
Могу ли я использовать поведение без файлов функций? У меня нет нетехнических пользователей, поэтому их написание для меня просто шум. Если кто-то не может прочитать мои тесты, которые я дал / когда /, то они не имеют никакого отношения к этому.
Вы можете использовать "Конечно" для выразительных утверждений (как в RSpec)
Парабены! Вы совершенно поразили меня кодом в magic.py. Я понятия не имел, что в Python возможны «методы расширения» (открытые классы).