Каковы основные различия между TDD и BDD?
https://stackoverflow.com/questions/2509
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Разработка через тестирование была в моде в сообществе .NET в течение последних нескольких лет.Недавно я услышал в сообществе ALT.NET недовольство по поводу BDD.Что это такое?Чем он отличается от TDD?
Решение
Я понимаю, что 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 г.
Видео выше давно пропало.Вот недавняя работа Ллевеллина Фалько: BDD против TDD (объяснение).Я нахожу его объяснение ясным и точным.
Другие советы
Для меня основное различие между BDD и TDD — это фокус и формулировка.И слова важны для передачи ваших намерений.
TDD фокусирует внимание на тестировании.А поскольку в «старом мире водопада» тесты идут после реализации, то такое мышление приводит к неправильному пониманию и поведению.
BDD фокусирует внимание на поведении и спецификациях, поэтому умы водопада отвлекаются.Таким образом, BDD легче понимать как практику проектирования, а не как практику тестирования.
Кажется, существует два типа BDD.
Первый — это оригинальный стиль, который обсуждает Дэн Норт и который стал причиной создания фреймворков стилей xBehave.На мой взгляд, этот стиль в первую очередь применим для приемочного тестирования или спецификации объектов предметной области.
Второй стиль — это то, что популяризировал Дэйв Астелс и который, на мой взгляд, представляет собой новую форму TDD, имеющую некоторые серьезные преимущества.Он фокусируется на поведении, а не на тестировании, а также на небольших тестовых классах, пытаясь достичь момента, когда у вас в основном будет одна строка для каждого метода спецификации (теста).Этот стиль подходит для всех уровней тестирования и может быть реализован с использованием любой существующей среды модульного тестирования, хотя более новые среды (стиль xSpec) помогают сосредоточить внимание на поведении, а не на тестировании.
Существует также группа BDD, которая может оказаться вам полезной:
Разработка через тестирование — это методология разработки программного обеспечения, основанная на тестировании, что означает, что она требует написания тестового кода перед написанием фактического кода, который будет тестироваться.По словам Кента Бека:
Стиль здесь состоит в том, чтобы написать несколько строк кода, а затем тест, который должен запускать или, даже лучше, написать тест, который не работает, а затем написать код, который заставит его запустить.
Выяснив, как написать один маленький кусочек кода, теперь, вместо того, чтобы просто кодировать, мы хотим получить немедленную обратную связь и практиковать «код немного, немного протестировать, немного кодировать, немного проверить». Итак, мы сразу же записываем тест для этого.
Итак, 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, назовем его проектированием, управляемым поведением.
Теперь рассмотрим популярную реализацию TDD — Unit Testing.Модули модульного тестирования обычно представляют собой один бит логики, который представляет собой наименьшую единицу работы, которую вы можете выполнить.
Когда вы объединяете эти блоки функциональным способом, чтобы описать желаемое поведение машины, вам необходимо понять поведение, которое вы описываете машине.Проектирование, основанное на поведении, фокусируется на проверке понимания разработчиками вариантов использования/требований/что угодно и проверяет реализацию каждой функции.BDD и TDD в целом служат важной цели информирования о дизайне и второй цели проверки правильности реализации, особенно когда она изменяется.Правильно выполненный BDD включает в себя бизнес и разработку (и контроль качества), тогда как модульное тестирование (возможно, ошибочно рассматриваемое как TDD, а не как один из типов TDD) обычно выполняется в бункере разработчиков.
Я бы добавил, что BDD-тесты служат жизненными требованиями.
BDD во многом представляет собой TDD, сделанный правильно.Однако BDD предлагает дополнительную ценность.Вот ссылка на это:
Вот быстрый снимок:
TDD — это всего лишь процесс тестирования кода перед его написанием!
DDD — это процесс получения информации о домене перед каждым циклом работы с кодом!
BDD — это реализация TDD, которая привносит некоторые аспекты DDD!
Надеюсь, это поможет!
Разница между разработкой через тестирование (TDD) и разработкой через поведение (BDD)
BDD фокусируется на поведенческом аспекте системы, а не на
аспект реализации системы, на котором фокусируется TDD.BDD дает более четкое понимание того, что должна делать система.
с точки зрения разработчика и заказчика.только TDD
дает разработчику понимание того, что должна делать система.BDD позволяет как разработчику, так и клиенту работать вместе с анализом требований, который содержится в исходном коде системы.
Нет никакой разницы между TDD и BDD.за исключением того, что вы можете лучше читать свои тесты и использовать их в качестве требований.Если вы пишете свои требования теми же словами, что и BDD-тесты, вы можете прийти от своего клиента с некоторыми из ваших тестов, определенными и готовыми к написанию кода.
