Насколько конкретны сценарии BDD?

Возьмите два разных способа описания одного и того же поведения.

Вариант А:

Given a customer has 50 items in their shopping cart
When they check out
Then they will receive a 10% discount on their order

Вариант Б:

Given a customer has a high volume of items in their shopping cart
When they check out
Then they will receive a high volume discount on their order

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

Второй более общий и не имеет ясности первого. Для его автоматизации потребуется включить значения «50» и «10» в реализации шага. С другой стороны, сценарий отражает основную потребность бизнеса: крупный клиент получает скидку. Если позже мы решим использовать «40» и «15», сценарий не должен измениться, потому что потребности основного бизнеса на самом деле не изменились (хотя пошаговая реализация изменится). Кроме того, термин «крупный клиент» кое-что сообщает о том, почему мы предоставляем им скидку.

Итак, что лучше? Скорее, при каких обстоятельствах я должен отдать предпочтение первому или второму?


bdd acceptance-testing
person Ryan Nelson    schedule 04.10.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Думаю, я выберу вариант А.

Дело в том, что сценарии BDD должны служить документацией системы.

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

Я думаю, что эта информация важна и не может быть скрыта от читателя.

Еще одним преимуществом является то, что он позволяет не разработчику (например, тестировщику) писать новые сценарии и проверять, что произойдет, если в корзине будет 1 товар или 100 товаров.

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

  • Что произойдет, если у нас будет более 50 товаров, например 100 товаров, есть ли другие скидки?
  • Что произойдет, если у нас есть 1 товар, конечно, нам не нужно применять скидку, или мы должны применить скидку на основе общей стоимости корзины, а не количества товаров в ней, кто-то, покупающий только один действительно дорогой товар, должен получить скидку слишком ?
  • 10% - единственный доступный тип скидки, есть ли у нас, например, скидки с фиксированной суммой? Есть ли у нас более сложные стратегии скидок?

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

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

person foobarcode    schedule 06.10.2012