Что я, как программист, должен знать о Behavior Driven Development?

Question

Чтобы поместить это в контекст. Мне нравится TDD. Сначала я люблю писать свои тесты и выражать то, что мне нужно, чтобы мой код делал, используя assertEquals, assertTrue и т. Д.

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

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

Так что мой вопрос таков. Какое значение имеет BDD для меня как для программиста? а) В контексте проектов я пишу для себя (или с другими программистами). б) в контексте работы с нетехническими заказчиками.

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

Answer 1

Чтобы ответить на вопрос (а), если у вас нет нетехнических заинтересованных сторон, то, возможно, Cucumber не подходит, но уверены ли вы, что у вас достаточно интеграционных тестов? Модульных тестов обычно недостаточно.

Answer 2

Мне нравится обсуждение этого видео о разнице между TDD и BDD: http://channel9.msdn.com/Series/mvcConf/mvcConf-2-Brandom-Satrom-BDD-in-ASPNET-MVC-using-SpecFlow-WatiN-and-WatiN-Test-Helpers (его инструменты .NET и не обязательно инструменты .NET, которые я использую, но концепции верны)

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

Answer 3

Я протестировал BDD в очень простом внутреннем проекте, а затем экспортировал его в сложный.

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

Таким образом, вы можете использовать один и тот же подход красно-зеленого-рефакторинга на двух уровнях.

Я нашел внешние тесты чрезвычайно полезными для сложного проекта.