Каковы основные различия между TDD и BDD?

Я понимаю, что BDD-это больше спецификация , чем тестирование . Он связан с доменным дизайном (разве вам не нравятся эти *DD аббревиатуры?).

Это связано с определенным способом написания пользовательских историй, включая высокоуровневые тесты. Пример Тома Тен Тиджа :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(В своей статье том продолжает непосредственно выполнять эту спецификацию теста в Ruby.)

Папа римский 31-го года- дан Норт . Вы найдете отличное введение в его статье Introducing BDD .

Вы найдете сравнение BDD и TDD в этом видео . Также мнение о BDD как "TDD done right" от Jeremy D. Miller

Обновление от 25 марта 2013 года

Видео выше уже некоторое время отсутствует. Вот недавняя работа Ллевеллина Фалько, BDD vs TDD (объяснено) . Я нахожу его объяснение ясным и по существу.

Для меня основное различие между BDD и TDD-это фокус и формулировка. А слова важны для передачи вашего намерения.

TDD направляет фокус на тестирование. А поскольку в "old waterfall world" тесты приходят после внедрения, то такое мышление приводит к неправильному пониманию и поведению.

BDD направляет внимание на поведение и спецификацию, и поэтому водопадные умы отвлекаются. Таким образом, BDD легче понять как практику проектирования, а не как практику тестирования.

По-видимому, существует два типа BDD.

Первый-это оригинальный стиль, который обсуждает Дэн Норт и который вызвал создание фреймворков стиля xBehave. Для меня этот стиль в первую очередь применим для приемо-сдаточного тестирования или спецификаций для объектов домена.

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

Существует также группа BDD, которая может вам пригодиться:

http://groups.google.com/group/behaviordrivendevelopment/

Разработка на основе тестов - это методология разработки программного обеспечения на основе тестов, которая означает, что она требует написания тестового кода перед написанием фактического кода, который будет проверяться. По словам Кента Бека:

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

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

Таким образом, TDD-это низкоуровневая техническая методология, которую программисты используют для создания чистого кода, который работает.

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

Как вы можете видеть, такие вопросы требуют сотрудничества между технологиями и бизнесом. Заинтересованные стороны бизнеса и эксперты по предметной области часто могут сказать инженерам, какие тесты кажутся им полезными—но только в том случае, если тесты являются тестами высокого уровня, которые имеют дело с важными аспектами бизнеса. BDD вызывает такие бизнес-тесты “examples,”, как в “tell me an example of how this feature should behave correctly,”, и оставляет слово “test” для низкоуровневых технических проверок, таких как проверка данных или тестирование интеграции API. Важно то, что хотя тесты могут быть созданы только программистами и тестировщиками, примеры могут быть собраны и проанализированы всей командой доставки—дизайнерами, аналитиками и так далее.

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

Сейчас общение с экспертами по бизнесу и предметной области звучит здорово, но мы все знаем, как это часто заканчивается на практике. Я начал свое путешествие с технологий как программист. Как программистов, нас учат писать код-алгоритмы, шаблоны проектирования, абстракции. Или, если вы дизайнер, вас учат проектировать —организовывать информацию и создавать красивые интерфейсы. Но когда мы получаем работу начального уровня, наши работодатели ожидают от нас "deliver value to the clients." и среди этих клиентов могут быть, например... банк. Но я почти ничего не знал о банковском деле—кроме того, как эффективно уменьшить баланс своего счета. Так что мне придется каким-то образом перевести то, что от меня ожидают, в код... Мне придется построить мост между банковским делом и моей технической экспертизой, если я хочу принести какую-то пользу. BDD помогает мне построить такой мост на стабильном фундаменте текучей коммуникации между командой доставки и экспертами домена.

Учить больше

Если вы хотите узнать больше о BDD, я написал книгу на эту тему. “Writing Great Specifications” исследует искусство анализа требований и поможет вам узнать, как построить отличный процесс BDD и использовать примеры в качестве основной части этого процесса. В книге рассказывается о вездесущем языке, сборе примеров и создании так называемых исполняемых спецификаций (автоматизированных тестов) из примеров—методов, которые помогают командам BDD поставлять отличное программное обеспечение в срок и по бюджету.

Если вы заинтересованы в покупке “Writing Great Specifications,”, вы можете сохранить 39% с промо-кодом 39nicieja2 :)

Я немного поэкспериментировал с подходом BDD, и мой преждевременный вывод заключается в том, что BDD хорошо подходит для реализации прецедента, но не для основных деталей. TDD все еще Рок на этом уровне.

BDD также используется в качестве средства связи. Цель состоит в том, чтобы написать исполняемые спецификации, которые могут быть поняты экспертами домена.

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

Статья в Википедии имеет объяснение:

Развитие, основанное на поведении

Но сам я не практиковал BDD.

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

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

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

Теперь рассмотрим популярную реализацию TDD-модульного тестирования. Единицы измерения в модульном тестировании обычно представляют собой один бит логики, который является самой маленькой единицей работы, которую вы можете сделать.

Когда вы объединяете эти блоки функциональным образом, чтобы описать желаемое поведение машин, вам нужно понять поведение, которое вы описываете машине. Дизайн, основанный на поведении, фокусируется на проверке понимания исполнителями использования Cases/Requirements/Whatever и проверяет реализацию каждой функции. BDD и TDD в целом служат важной цели информирования дизайна и второй цели проверки правильности реализации, особенно когда она изменяется. BDD done right включает в себя biz и dev (и qa), в то время как модульное тестирование (возможно, неправильно рассматриваемое как TDD, а не один тип TDD) обычно выполняется в силосе dev.

Я бы добавил, что BDD тестов служат жизненными требованиями.

BDD в значительной степени является TDD сделанным правильно. Однако есть и дополнительная ценность, которую предлагает BDD. Вот ссылка на это:

BDD - это больше, чем “TDD done right”

Вот быстрый снимок:

• TDD - это просто процесс тестирования кода перед его написанием!

• DDD-это процесс получения информации о домене перед каждым циклом трогательного кода!

• BDD-это реализация TDD, которая включает в себя некоторые аспекты DDD!

Надеюсь, это поможет!

Разница между тестовой разработкой (TDD) и поведенческой разработкой (BDD )

• BDD фокусируется на поведенческом аспекте системы, а не на поведенческом аспекте самой системы.
  аспект реализации системы, на котором фокусируется TDD.

• BDD дает более четкое представление о том, что должна делать система
  с точки зрения разработчика и заказчика. Только TDD
  дает разработчику понимание того, что должна делать система.

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

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