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

Test Driven Development была яростью в сообществе .NET за последние несколько лет. В последнее время я слышал ворчание в сообществе ALT.NET о BDD. Что это? Что отличает его от TDD?

ОТВЕТЫ

Ответ 1

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

Он связан с определенным способом написания историй пользователей, включая тесты высокого уровня. Пример Tom ten Thij:

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 Dan North. Вы найдете замечательное введение в статью Введение в BDD.

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

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

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

Ответ 2

Для меня основное различие между BDD и TDD - фокус и формулировка. И слова важны для передачи ваших намерений.

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

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

Ответ 3

Кажется, существует два типа BDD.

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

Подробнее

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

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

Ответ 5

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

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

Ответ 6

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

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

Поведенческая разработка

Не практиковать сам BDD.

Ответ 7

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

Ответ 8

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

Ответ 9

Рассмотрим основное преимущество TDD как дизайна. Его следует назвать Test Driven Design. BDD - это подмножество TDD, называемое Behavior Driven Design.

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

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

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

Ответ 10

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

BDD больше, чем "TDD done right"

Ответ 11

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

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

  • DDD - это процесс информирования о Домене перед каждым циклом касания кода!

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

Ключ к BDD заключается в том, что он может предотвратить проблемы; он не гарантирован. Проблемы, такие как организация плохого кода, плохая практика проектирования и т.д., По-прежнему сохраняются. У вас будет меньше шансов написать плохие тесты и, следовательно, иметь более надежные функции.