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

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

Я понимаю, что 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 (объяснено) . Я нахожу его объяснение ясным и по существу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выучить больше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BDD - это больше, чем «TDD сделано правильно»

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

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

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

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

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

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

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

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

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

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