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

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

Ответов (12)

Решение

Я понимаю, что BDD - это больше спецификация, чем тестирование . Он связан с Domain Driven Design (разве вам не нравятся эти * аббревиатуры 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» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учить больше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавлю, что тесты BDD служат жизненной необходимостью.