BDD — TDD в виде BDD

В TDD термин «приемочные испытания» вводит в заблуждение. Приемочные тесты фактически представляют ожидаемое поведение системы. В Agile практиках подчеркивается сотрудничество всей команды и взаимодействия с заказчиком и другими заинтересованными сторонами. Это привело к необходимости использования терминов, которые легко понимают все участники проекта.

TDD заставляет задуматься о требуемом поведении, и поэтому термин «поведение» более полезен, чем термин «тест» . BDD — это разработка через тестирование со словарем, который фокусируется на поведении, а не на тестах.

По словам Дэна Норта, «я обнаружил, что переход от мышления в тестах к мышлению в поведении настолько глубок, что я начал называть TDD« BDD »или« Поведение, ориентированное на поведение ». TDD фокусируется на том, как что-то будет работать, BDD фокусируется на том, почему мы строим это вообще.

BDD отвечает на следующие вопросы, с которыми часто сталкиваются разработчики:

Эти ответы приводят к структуре истории следующим образом —

Рамочная история

Как [роль]

Я хочу [Особенность]

так что [выгода]

Это означает: «Когда функция выполняется, получаемая выгода для лица, играющего роль. ‘

BDD далее отвечает на следующие вопросы —

Эти ответы приводят в пример структуры следующим образом —

Пример платформы

Учитывая некоторый начальный контекст,

Когда происходит событие,

Затем обеспечьте некоторые результаты.

Это означает: «Начиная с исходного контекста, когда происходит определенное событие, мы знаем, какими должны быть результаты».

Таким образом, пример показывает ожидаемое поведение системы. Примеры используются для иллюстрации различных сценариев системы.

История и сценарии

Давайте рассмотрим следующую иллюстрацию Дэна Норта о системе банкоматов.

История

Как клиент,

Я хочу снять наличные в банкомате,

так что мне не нужно ждать очереди в банке.

Сценарии

Есть два возможных сценария этой истории.

Сценарий 1 — счет в кредит

Учитывая, что счет в кредит

И карта действительна

И диспенсер содержит деньги

Когда клиент просит наличные

Затем убедитесь, что учетная запись списана

И убедитесь, что деньги выдаются

И убедитесь, что карта возвращается

Сценарий 2 — Счет превышен лимит овердрафта

Учитывая, что счет снят

И карта действительна

Когда клиент просит наличные

Затем убедитесь, что отображается сообщение об отказе

И убедитесь, что деньги не выдаются

И убедитесь, что карта возвращается

Событие одинаково в обоих сценариях, но контекст отличается. Следовательно, результаты разные.

Цикл разработки

Цикл разработки для BDD является внешним подходом.

Шаг 1 — Напишите пример бизнес-ценности высокого уровня (с использованием Cucumber или RSpec / Capybara), который станет красным. (RSpec создает среду BDD на языке Ruby)

Шаг 2 — Напишите низкоуровневый (внутренний) пример RSpec для первого шага реализации, который становится красным.

Шаг 3 — Реализуйте минимальный код для прохождения этого примера более низкого уровня, посмотрите, как он становится зеленым.

Шаг 4 — Напишите следующий пример RSpec нижнего уровня, нажимая на прохождение шага 1, который становится красным.

Шаг 5 — Повторяйте шаги Шаг 3 и Шаг 4, пока пример высокого уровня на Шаге 1 не станет зеленым.

Примечание . Необходимо учитывать следующее:

Красный / зеленый статус — это статус разрешения.

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

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