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

Это возможно, в некотором роде. Вы можете добавить /u/0, /u/1 и т. Д. В URL-путь, чтобы принудить пользователя к первому входу в систему, второму входу в систему, но, конечно, это предполагает, что вы знаете, в какие учетные записи и в каком порядке. Мессинг о том, что большое число, скажем, /u/999, решает вопрос о последнем вошедшем в систему пользователе.

Кроме того, это работает https://drive.google.com/drive/u/user1@gmail.com/my-drive против https://drive.google.com/drive/u/user2@gmail.com/my-drive. Однако я не знаю, можно ли использовать тот же синтаксис URL для добавления электронного письма в webViewLink.

Обратите внимание, что это не является официальным и может измениться.

5
задан doppelgreener 8 April 2014 в 03:37
поделиться

4 ответа

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

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

    result = view.GetData(
      CustomerIs.Valid, 
      CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
    
  2. Сообщение уровня служб, о поведении обработки исключений (ActionPolicy введен в декораторов):

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

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

4
ответ дан 14 December 2019 в 09:02
поделиться

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

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

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

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

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

2
ответ дан 14 December 2019 в 09:02
поделиться

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

По тому, как это не было глазным яблоком проект UI. Это был проект интеграции синхронизация данных из веб-сервиса в базу данных. Таким образом, это показывает, что GWT работает даже на не - "глазное яблоко" UIs.

1
ответ дан 14 December 2019 в 09:02
поделиться

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

0
ответ дан 14 December 2019 в 09:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: