Различия TDD и BDD

Question

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

Вот забавный вопрос. С чего мне начать? Должен ли я начать с высокоуровневых тестов BDD? Начать с тестов TDD низкого уровня?

Answer 1

Честно говоря, я не вижу разницы между BDD и TDD.

Это потому что их нет.

Я имею в виду, что оба - просто тесты, если то, что ожидается, произойдет.

Это неправильно. BDD и TDD не имеют ничего общего с тестированием. Никто. Нада. Шиш. Zip. Никс. Ни в малейшей степени.

К сожалению, в TDD слово "test" встречается практически во всем (не только в его названии, но также в тестовой среде, модульном тесте, TestCase (класс, от которого вы наследуете tpyically), FooTest (класс который обычно содержит ваши тесты), testBar (типичный шаблон именования для метода тестирования), плюс множество терминов, связанных с тестами, такими как «утверждение» и «проверка»), что заставляет некоторых людей верить, что это на самом деле имеет какое-то отношение к тестам. Итак, некоторые умные люди сказали: «Эй, давай просто сменим имя», чтобы убрать любую путаницу.

И это то, что BDD. Это просто TDD с любой терминологией, связанной с тестами, замененной терминологией, связанной с примерами поведения:

• Test & rarr; Пример
• Утверждение & rarr; Expectation
• assert & rarr; should
• Единица & rarr; Поведение
• Проверка & rarr; Спецификация

BDD - это просто TDD с разными словами. Если вы делаете TDD правильно, вы делаете BDD. Разница в том, что & ndash; при условии, что вы верите хотя бы в слабую форму гипотезы Сапир-Уорфа - ndash; разные слова упрощают правильное выполнение.

Answer 2

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

TDD с точки зрения разработчиков и фокусируется на реализации одного устройства / класса / функции. Он выигрывает, среди прочего, от лучшей архитектуры (дизайн для тестируемости, меньшая связь между модулями).

С технической точки зрения (как написать "тест") они похожи.

Я бы (с гибкой точки зрения ) начал с одной bdd-userstory и реализовал ее с использованием TDD.

Answer 3

Из того, что я собрал в Википедии, BDD включает в себя приемочные испытания и тестирование качества, которые невозможно выполнить без участия заинтересованных сторон / пользователей.Также BDD использует естественный язык для определения своего теста, в то время как TDD обычно использует язык программирования.Может быть некоторое совпадение между этими двумя понятиями, но я думаю, что основное отличие заключается не в неопределенности, а в языке BDD.Это?Я предполагаю, что если вы делаете снизу вверх, что вы собираетесь сначала написать TDD, и как только вы достигнете более высокого уровня, вы будете использовать BDD, чтобы проверить, работают ли эти функции, как ожидалось.Было бы так, что BDD ориентирован на проблемную область, в то время как TDD более ориентирован на область решения.

Answer 4

Просто скопировав ответ от Мэтью Флинна , с которым я согласен больше, чем "TDD и BDD не имеют ничего общего с тестами":

Behavior Driven Development является расширением / пересмотром Test Driven Development. Его цель - помочь людям, разрабатывающим систему (то есть разработчикам) определить соответствующие тесты для написания, то есть тесты, отражающие поведение, желаемое заинтересованными сторонами. Эффект в конечном итоге остается прежним - разработайте тест, а затем разработайте код / ​​систему, которая пройдет тест. Надежда в BDD состоит в том, что тесты действительно полезны, чтобы показать, что система соответствует требованиям.

UPDATE

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

Answer 5

BDD - это правильное определение TDD.Он обеспечивает "структуру и участие" в вашем TDD.Он поможет вам в правильном тестировании и правильном тестировании.Вот фантастический небольшой пост на BDD и TDD,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 6

Фантастическая статья о различиях между TDD и BDD:

http://www.lostechies.com/blogs/sean_chambers/archive/2008/12/07/starting-with-bdd-vs-starting-with-tdd.aspx

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

Answer 7

Я думаю, что самый большой вклад BDD по сравнению с TDD или любыми другими подходами - сделать людей, не являющихся техническими специалистами (владельцы продуктов / клиенты), частью процесса разработки программного обеспечения на всех уровнях.

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

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

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

Answer 8

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

Answer 9

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