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

unit-testing tdd bdd

41799 просмотра

14 ответа

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

Автор: NotMyself Источник Размещён: 24.08.2019 05:53

Ответы (14)


102 плюса

Решение

Я понимаю, что 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 г. обновление

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

Автор: Christian Lescuyer Размещён: 05.08.2008 04:36

17 плюса

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

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

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

Автор: Juha Pohjalainen Размещён: 08.09.2008 06:36

13 плюса

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

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

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

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

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

Автор: Colin Jack Размещён: 10.09.2008 04:00

7 плюса

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

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

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

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

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

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

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

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

Учить больше

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

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

Автор: thion Размещён: 12.02.2017 04:43

6 плюса

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

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

Автор: Thomas Eyde Размещён: 27.08.2008 08:59

2 плюса

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

Автор: palehorse Размещён: 05.08.2008 04:11

2 плюса

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

Автор: Uma Mahesh Varma Размещён: 25.05.2009 04:09

2 плюса

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

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

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

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

Автор: Michael Stum Размещён: 05.08.2008 04:06

2 плюса

Рассмотрим основное преимущество 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 служат жизненными требованиями.

Автор: phil v Размещён: 28.05.2015 10:36

1 плюс

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

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

Автор: Neel Размещён: 29.07.2010 10:25

1 плюс

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

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

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

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

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

Автор: Snehal Masne Размещён: 18.01.2016 03:01

1 плюс

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

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

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

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

Автор: rahul patil Размещён: 09.06.2017 11:49

0 плюса

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

Автор: Mihai Размещён: 07.10.2014 08:52

0 плюса

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

Автор: saurabh singh Размещён: 24.08.2019 02:53
32x32