Какие-нибудь истории успеха BDD там?

Question

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

Итак, мой вопрос к сообществу: есть ли у вас проект, который успешно использовал BDD? Если да, то какие выгоды вы получили и что могло быть лучше? Вы бы сделали BDD снова? Вы бы порекомендовали это другим людям?

Answer 1

Мы несколько использовали BDD на уровне кода в различных сценариях (проекты с открытым исходным кодом и ND).

1. Указание представления в сценарии MVC, какой тип ввода принимать от пользователя ( Проверка DDD и управляемый по правилам интерфейс пользователя в .NET )

   result = view.GetData(
     CustomerIs.Valid, 
     CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
   

2. Сообщение сервисному уровню о поведении обработки исключений ( ActionPolicy вводится в декораторы):

   var policy = ActionPolicy
     .Handle<WebException>()
     .Retry(3);
   

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

Answer 2

Я был в небольшой команде, которая использовала BDD на сайте.

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

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

Это все равно было бы BDD, только без этой милой уловки попытки превратить язык в язык, обозначенный random_looking.set of_Punctuation скорее, чем simple.spaces, но это было только мое сварливое отношение старого программиста, все остальные 100% доволен этим.

Сайт доступен и полностью функционален, поэтому я бы назвал его успешным: Посмотрите

Answer 3

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

Между прочим, это не был проект с интерфейсом для глаз. Это был интеграционный проект, синхронизирующий данные из веб-службы в базе данных. Таким образом, это показывает, что GWT работает даже для не «глазных» интерфейсов.

Answer 4

Я с большим успехом использовал стиль Context-Specification в нескольких проектах (используя MSpec). Я все еще пытаюсь понять реальные преимущества стиля Сценария. Чем больше я использую стиль спецификации контекста, тем больше он мне нравится, и тем труднее мои приложения.