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

голоса
119

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

Задан 05/08/2008 в 16:58
источник пользователем
На других языках...                            


15 ответов

голоса
94

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

Это связанно с определенным способом , чтобы писать пользовательские истории, в том числе тестов на высоком уровень. Пример по Том десять 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 в этом видео . Также мнение о BDD , как «TDD сделано правильно» по Джереми Д. Миллер

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

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

Ответил 05/08/2008 d 17:36
источник пользователем

голоса
17

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

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

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

Ответил 08/09/2008 d 19:36
источник пользователем

голоса
13

Там, кажется, два типа BDD.

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

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

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

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

Ответил 10/09/2008 d 17:00
источник пользователем

голоса
6

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

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

Ответил 27/08/2008 d 21:59
источник пользователем

голоса
5

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

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

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

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

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

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

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

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

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

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

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

Ответил 12/02/2017 d 16:43
источник пользователем

голоса
2

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

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

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

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

Ответил 28/05/2015 d 22:36
источник пользователем

голоса
2

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

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

Ответил 29/07/2010 d 11:25
источник пользователем

голоса
2

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

Ответил 25/05/2009 d 05:09
источник пользователем

голоса
2

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

Ответил 05/08/2008 d 17:11
источник пользователем

голоса
2

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

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

Развитие Поведение управляемой

Не практикует BDD себя, хотя.

Ответил 05/08/2008 d 17:06
источник пользователем

голоса
1

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

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

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

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

Ответил 09/06/2017 d 23:49
источник пользователем

голоса
1

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

  • TDD является только процесс тестирования кода перед записью!

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

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

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

Ответил 18/01/2016 d 03:01
источник пользователем

голоса
0

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

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

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

Ответил 18/09/2016 d 09:59
источник пользователем

голоса
0

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

Ответил 07/10/2014 d 09:52
источник пользователем

голоса
-1

Этот блог дает интересную точку зрения о различиях между TDD, BDD и ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

Ответил 20/05/2014 d 19:32
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more