BDD - TDD в духе BDD

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

TDD заставляет задуматься о необходимом Behavior и, следовательно, термин "поведение" более полезен, чем термин ‘Test’. BDD - это разработка, управляемая тестированием, со словарем, который фокусируется на поведении, а не на тестах.

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

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

Вопрос	Ответ
Когда начать?	снаружи
Что тестировать?	Истории пользователей
Что не тестировать?	что-нибудь еще

Эти ответы приводят к следующей структуре истории:

Story Framework

Как [Role]

я хочу [Feature]

так что [Benefit]

Это означает: «Когда Feature выполняется, в результате Benefit для человека, играющего Role.'

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

Вопрос	Ответ
Сколько тестировать за один раз?	очень мало сфокусированный
Как назвать их тесты?	шаблон предложения
Как понять, почему тест не проходит	документация

Эти ответы приводят к следующей структуре примера:

Example Framework

Given некоторый начальный контекст,

When событие происходит,

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

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

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

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

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

История

As a покупатель,

I want снимать наличные в банкомате,

so that Мне не нужно стоять в очереди в банке.

Сценарии

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

Scenario 1 - Счет в кредит

Given счет в кредите

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

And в диспенсере есть наличные

When клиент просит наличные

Then обеспечить дебетование счета

And обеспечить выдачу наличных

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

Scenario 2 - Счет превышает лимит овердрафта

Given счет овердрафта

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

When клиент просит наличные

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

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

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

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

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

Цикл разработки BDD - это outside-in подход.

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

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

Step 3 - Внедрите минимальный код для передачи этого примера нижнего уровня, чтобы он стал зеленым.

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

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

Note - Следует иметь в виду следующие моменты -

• Red/green state - это статус разрешения.

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

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