Окупается ли BDD?

Question

Я немного знаком с rspec [Ruby] и specs [Scala]. Вчера я прошел репетитор по огурцам. Что мне не понравилось в Cucumber, так это то, что в дополнение к описанию сценариев (как вы это делали бы при тестировании в стиле спецификаций или xUnit) вы должны реализовать дополнительный уровень косвенности: перевод шагов сценария в выражения ruby. Для меня создание ненужных (?) Дополнительных слоев косвенного восприятия похоже на "тяжелый" J2EE-путь, а не на "легкий" рубиновый путь. Является ли понятность «экспертами в области» единственным преимуществом Cucumber? Или есть какие-то неочевидные (технические?) Преимущества и для разработчика / тестера?

Answer 1

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

Акт привлечения заинтересованных сторон бизнеса окупается, потому что каждый получаетдля лучшего понимания они начинают использовать один и тот же язык и переносить этот язык в код (см. «Вездесущий язык» для Domain Driven Design), что может привести к лучшим оценкам, оценке объема, обсуждению вариантов достижения той же цели и т. д. и т. д. и т. д..

Конечно, есть и другие способы достижения целей.Например, в нашем проекте на C # мы говорим о сценариях, пишем их в вики, а затем реализуем их, используя небольшой пользовательский язык, специфичный для предметной области, такой как этот .То же самое можно сделать и в Ruby.

BDD - это процесс изучения мест, где мы думали, что знаем, что делаем, но оказалось, что мы ошибались - открытие невежества .С Feature Injection и примерами на уровне единиц это происходит на нескольких уровнях детализации, вплоть до самого видения проекта.Он имеет тенденцию окупаться, но вам не нужна среда BDD для выполнения BDD .

Разговоры в BDD являются важными битами, а не инструментом, который вы используете для их захвата(Я помог написать JBehave и до сих пор считаю, что это правда).Автоматизация регрессионных тестов также важна, чтобы сократить ручные усилия, которые растут с ростом кодовой базы, а Cucumber, DSL и другие инструменты BDD дают вам это как очень хороший побочный продукт, который также поможет вам отслеживать и выводить общее понимание.

Редактировать: Я должен отметить, что повторное использование шагов также важно, но не имеет большого значения, используете ли вы для этого среду BDD или DSL.Это действительно делает разницу между DSL и просто процедурно имитирует каждое взаимодействие с пользователем.

Answer 2

BDD, с практической точки зрения, является синонимом TDD.Rspec - это тестовая среда BDD, а также Cucumber.

То, что заинтересованные стороны могут прочитать и понять спецификации приемки Cucumber, безусловно, является ключевым преимуществом, но сам по себе этот факт действительно не дает реальной выгоды от Cucumber.Ваши особенности и сценарии должны стать более специфичными, поскольку выполняемая для них работа проходит через поток создания ценности цикла разработки вашей команды.

В некоторых командах аналитик может планировать работу в начале цикла.Иногда этот аналитик пишет спецификации приемки корнишонов, но кто бы ни писал первый черновик, вы ожидаете, что они будут довольно грубыми.Они могут не охватывать каждый не счастливый путь.

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

По моему опыту, тестеры взрастили еще более критический взгляд, и, таким образом, это не редкостьчтобы увидеть их добавить еще больше сценариев и функций.Тестеры также могут обнаруживать дефекты, которые должны быть добавлены в кики, чтобы защитить нас от регрессии.

Дело в том, что, помимо предоставления исполняемой документации для нашего кода, Cucumber также предоставляет репозиторий для состоянияразговоры команды с разрабатываемыми функциями.

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

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

Answer 3

Это зависит от того, чего вы хотите достичь.

Огурец добавляет накладных расходов, может быть сложно привыкнуть, требует времени на освоение.

Если вы хотите, чтобы эксперты вашего домена могли читать ваши тесты, вам обязательно стоит попробовать.

С другой стороны, если разработчики - единственные, кто читает ваши тесты, вы, вероятно, можете придерживаться rspec / unit-test / etc. и напишите свои интеграционные тесты в этих рамках. Однако вы можете получить более читаемую документацию высокого уровня, используя огурец. Смотрите, например, rspec 2 core описания функций в огурце.