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

Question

Разработка через тестирование была в моде в сообществе .NET в течение последних нескольких лет. Недавно я слышал ворчание в сообществе ALT.NET о BDD. Что это? Чем он отличается от TDD?

Answer 1

Я понимаю, что 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.)

Папа БДД - Дан Северный . Вы найдете отличное введение в его статье Представление BDD .

В этом видео вы найдете сравнение BDD и TDD. Также мнение о BDD как "TDD сделано правильно" Джереми Д. Миллер

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

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

Answer 2

Для меня основная разница между BDD и TDD - это фокус и формулировка. И слова важны для сообщения вашего намерения.

TDD направляет внимание на тестирование. И поскольку в «старом мире водопадов» тесты приходят после реализации, такое мышление ведет к неправильному пониманию и поведению.

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

Answer 3

Похоже, есть два типа БДД.

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

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

Существует также группа BDD, которая может оказаться полезной:

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

Answer 4

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

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

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

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

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

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

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

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

Узнать больше

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

Если вы заинтересованы в покупке «Написание отличных спецификаций» , вы можете сэкономить 39% с промо-кодом 39nicieja2 :)

Answer 5

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

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

Answer 6

Считайте, что основным преимуществом TDD является дизайн. Он должен называться Test Driven Design. BDD является подмножеством TDD, назовите его Behavior Driven Design.

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

Когда вы объединяете эти блоки функциональным способом для описания желаемого поведения машин, вам необходимо понимать поведение, которое вы описываете для машины. Behavior Driven Design фокусируется на проверке понимания разработчиками вариантов использования / требований / чего бы то ни было и проверяет реализацию каждой функции. BDD и TDD в целом служат важной цели информирования проекта и второй цели проверки правильности реализации, особенно когда она изменяется. Правильно выполненное BDD включает в себя biz и dev (и qa), в то время как модульное тестирование (возможно, неправильно рассматриваемое как TDD, а не как один тип TDD) обычно выполняется в хранилище dev.

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

Answer 7

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

Answer 8

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

Answer 9

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

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

Разработка на основе поведения

Хотя сам не практикую BDD.

Answer 10

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

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

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

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