Является ли BDD заменой TDD?

Question

Интересно, является ли BDD заменой TDD ? Теперь я понимаю, что в окончательном BDD у нас больше нет модульных тестов. Вместо этого есть истории / сценарии / функции и «этапы тестирования». И это выглядит как полная замена TDD для меня. TDD мертв?

Answer 1

Совсем нет.BDD - это просто вариант TDD.

В TDD вы формулируете свои требования как исполняемый тест, а затем пишете производственный код для его выполнения.BDD не делает ничего, кроме как переформулирует эти требования в более удобочитаемую форму и, таким образом, делает тесты несколько более многословными для читателя-человека, который смотрит на протокол испытаний.(Кстати: для этого BDD требуется гораздо больше кода, чем при традиционном модульном тестировании на основе данных ...)

Вот и все.

Thomas

Answer 2

У меня другая точка зрения на это, чем у других респондентов.

Дэн Норт создал BDD, выполняя свою консультационную работу по TDD, когда он увидел, что многие люди были озадачены «тестовой» частью, потому что у них был опыт тестирования, он решил сменить имя. Итак, сначала BDD был именно тем, чем является TDD, объяснил правильно. После этого Дэн начал расширять идею использования исполняемых спецификаций (модульных тестов) для реализации реализаций, добавляя другие уровни спецификации. Он был вдохновлен пользовательскими историями, поэтому самый простой BDD, реализованный большинством инструментов, позволяет вам писать требования в виде сценариев пользовательских историй, чем писать код, который генерирует модульные тесты, и чем из этих модульных тестов вы работаете над реализацией. Итак, теперь вы видите, что по сравнению с TDD существует другой уровень спецификации - пользовательские истории. Многие инструменты включают готовые переводы пользовательских историй в тесты, поэтому многие забывают о них, как и вы, но они все еще там и не могут быть полностью опущены - как отмечалось, практически, а также теоретически, программирование пользовательских историй неэффективно. Но дело не в этом: вы используете пользовательские истории, чтобы собрать требования от заинтересованных сторон и доказать, что вы реализовали их, выполнив приемочные тесты.

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

Answer 3

Габриэль почти прав.

Принципиальное отличие на уровне единицы состоит в том, что BDD использует слово «должен» вместо «тест». Оказывается, когда вы говорите «тест», большинство людей начинают задумываться о том, что делает их код и как они могут его тестировать. С BDD мы рассматриваем - и задаем вопрос - что должен делать наш код . Это тонкий, но важный момент, и если вы хотите узнать, почему это мощно, прочитайте о нейролингвистическом программировании - особенно о том, как слова влияют на мысли и модель мира. В качестве краткого примера, многие новички в TDD начинают закреплять свой код, чтобы никто не смог его взломать. BDDers, как правило, предоставляют примеры, которые демонстрируют ценность их кода, чтобы люди могли безопасно изменять свой код.

Дэн понял, когда разговаривал с Крисом Мэттсом и писал JBehave, что он может поднять это до уровня сценария (сценарии не совсем такие же, как истории). Поскольку мы уже использовали слово «следует» на уровне единиц, имело смысл начать писать вещи на английском языке (например, я склонен использовать «должен дать мне», а не «должен вернуться»). Разработка на основе приемочных испытаний - ATDD - существует уже давно, но это был AFAIK первый раз, когда кто-то писал их на английском языке с участием заинтересованных сторон.

Это больше, чем просто замена TDD. Это другой способ мышления о тестировании - очень сосредоточенный на обучении, преднамеренном обнаружении областей, где мы, возможно, думали, что мы знали, что мы делаем, но не знали, раскрывая и помогая нам разрешить невежество и недоразумение. Это работает на многих уровнях. Функция «Впрыскивание» Криса Мэтта переносит это в пространство более высокого уровня, вплоть до видения проекта.

Мы все еще пишем примеры - или спецификации, если хотите, - также на уровне единиц, но на самом деле, это шаблон, который намного выше, чем даже сценарии. Если вы хотите узнать больше, вы можете найти мой блог полезным , Dan's даже лучше . Кроме того, у Криса есть комикс о реальных опционах , в котором описаны некоторые из упомянутых мной шаблонов.

Answer 4

BDD должен подчеркивать поведение с точки зрения пользователя и идеально подходит для проведения сквозных тестов, своего рода DSL для бедного человека для разработки на основе приемочных испытаний.Он может дополнять TDD, но он определенно не является заменой.TDD - это как проектная деятельность, так и тестирование (плохо спроектированный код сложно проверить -> модульные тесты поощряют хороший дизайн).BDD не имеет ничего общего с дизайном.Это своего рода тестирование, которое абстрагируется от кода в целом.

На практике BDD приводит к гораздо большему количеству кода, чем обычные приемочные тесты, поэтому я предпочитаю создавать внутренний DSL в обычномязык программирования, чтобы вести мои приемочные тесты.Что касается юнит-тестов, BDD подчеркивает поведение с точки зрения пользователя и поэтому не должен использоваться на уровне юнитов.

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

Answer 5

Вы можете использовать термин « Спецификация по Примеру » для BDD, что подчеркивает важный аспект этой методологии: Совместная спецификация - через семинары по спецификациям для всей команды, небольшие собрания или обзоры телеконференций. В рамках этих сессий с различными заинтересованными сторонами используются конкретные примеры для иллюстрации требований. Обсуждение требований в форме примеров помогает создать общее понимание предметной области и возможных решений.

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

Answer 6

Насколько я понимаю, преимущества BDD перед TDD таковы:

• Отделение тестов от деталей реализации.Таким образом, файлы компонентов не будут повреждены, только файлы шагов, если вы измените реализацию, но не поведение.
• Повторное использование существующего кода тестирования.Вы можете сделать то же самое с помощью TDD, если вы определяете пользовательские утверждения, фикстуры, помощники и т. Д. Но мы (по крайней мере, я) обычно копируем-тестируем код (плохая привычка).Намного проще использовать код BDD.Будет еще какое-то повторение, но, по крайней мере, оно будет в корнишоне.

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

Answer 7

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

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/