Я честно не вижу разницы между BDD и TDD. Я имею в виду, что оба являются просто испытаниями, если ожидаемое произойдет. Я видел тесты BDD, которые настолько сфокусированы, что они практически считаются TDD-тестами, и я видел тесты TDD, которые настолько расплывчаты, что у них черный ящик большого количества кода. Позвольте мне просто сказать, что я уверен, что оба лучше.
Вот забавный вопрос. С чего начать? Я начинаю с тестов BDD на высоком уровне? Я начинаю с тестов TDD низкого уровня?
Я честно не вижу разницы между BDD и TDD.
Это потому, что его нет.
Я имею в виду, что оба являются просто проверками, если ожидается, что ожидается.
Это неправильно. BDD и TDD не имеют абсолютно никакого отношения к тестированию. Никто. Нада. Шиш. Zip. Никс. Не в малейшей степени.
К сожалению, TDD имеет слово "тест" почти во всем (не только в его имени, но и в тестовой среде, unit test, TestCase (класс, на который вы наследуете), FooTest ( класс, который обычно проводит ваши тесты), testBar (типичный шаблон именования для тестового метода), плюс множество терминологических терминов, таких как "утверждение" и "проверка" ), что заставляет некоторых людей полагать, что на самом деле это действительно что-то общее с тестами. Итак, некоторые умные люди сказали: "Эй, позвольте просто изменить имя", чтобы устранить любую путаницу.
И что такое BDD. Это просто TDD с любой терминологической терминологией, замененной терминологией, относящейся к поведению:
assert → shouldBDD - это просто TDD с разными словами. Если вы делаете TDD правильно, вы делаете BDD. Разница в том, что – если вы верите, по крайней мере, в слабую форму гипотезы Сапира-Уорфа – разные слова позволяют сделать это правильно.
BDD имеет точку зрения клиентов и фокусируется на проверке поведения всей системы.
TDD имеет точку зрения разработчиков и фокусируется на реализации одного элемента/класса/функции. Он выигрывает среди других благодаря лучшей архитектуре (дизайн для тестирования, отсутствие связи между модулями).
Из технической точки зрения (как написать "тест" ) они похожи.
Я бы (из подвижной точки зрения) начал с одной bdd-userstory и реализовал ее с помощью TDD.
Из того, что я собрал в Википедии, BDD включает прием и тест QA, которые не могут быть выполнены без участия заинтересованных сторон/пользователей. Кроме того, BDD использует естественный язык для указания своего теста, в то время как TDD обычно использует язык программирования. Между ними может быть какое-то совпадение, но я считаю, что это не туманность, а язык BDD, что является основным отличием.
Что касается того, где вы должны начать, что действительно зависит от вашего процесса разработки, не так ли? Я предполагаю, что если вы делаете снизу вверх, что сначала собираетесь написать TDD, и как только вы достигнете более высокого уровня, вы будете использовать BDD, чтобы проверить, работают ли эти функции как ожидалось.
Как отмечалось в k3b: основное различие заключается в том, что BDD ориентирован на проблемную область, тогда как TDD является более ориентированной областью решения.
Просто скопировав ответ от Matthew Flynn, который я согласен больше, чем "TDD и BDD не имеют ничего общего с тестами":
Разработка, управляемая поведением, является расширением/пересмотром Test Driven Development. Его цель - помочь разработчикам системы (например, разработчикам) определить подходящие тесты для написания, т.е. Тесты, которые отражают поведение, желаемое заинтересованными сторонами. Эффект заканчивается тем же самым - разработать тест, а затем разработать код/систему, которая проходит тест. Надежда в BDD заключается в том, что тесты действительно полезны, показывая, что система удовлетворяет требованиям.
ОБНОВЛЕНИЕ
Единицы кода (отдельные методы) могут быть слишком гранулированными, чтобы представлять поведение, представленное поведенческими тестами, но вы все равно должны тестировать их с помощью модульных тестов, чтобы гарантировать их правильную работу. Если это то, что вы имеете в виду под тестами "TDD", то да, вы все еще нуждаетесь в них.
Фантастическая статья о различиях между TDD и BDD:
Должно предоставить вам все, что вам нужно знать, включая проблемы с обоими и примерами.
BDD собирается получить право TDD. Он обеспечивает "структуру и дициклин" для вашего TDD. Это поможет вам проверить правильность и сделать правильный объем теста. Вот фантастический небольшой пост на BDD и TDD,
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
Терминология отличается, но в моей работе я использую TDD для детализации dev, главным образом для unit test, а BDD - более высокий уровень, для клиента, QA или нетехнического человека.
Основное различие - это только формулировка. BDD использует более подробный стиль, чтобы его можно было прочитать почти как предложение.
Я думаю, что самый большой вклад BDD в TDD или любые другие подходы делает нетехнических людей (владельцев продуктов/клиентов) частью процесса разработки программного обеспечения на всех уровнях.
Написание исполняемых сценариев на естественных языках почти перекрыло разрыв между требованием и доставкой.
Владельцы продуктов сами могут запускать сценарии, которые он написал, и тестировать с помощью разных наборов данных, если он хочет играть вокруг поведения кода, написанного командой разработчиков.
Это потрясающе! Клиент сидит прямо в центре и точно не просто спрашивает, чего он действительно хочет, но и проверяет и испытывает результаты.