BDD (программирование)

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

BDD (сокр. от англ. Behavior-driven development, дословно «разработка через поведение») — это процесс разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD).

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

Считается, что данный подход эффективен, когда предметная область, в которой работает программный продукт, описывается очень комплексно.

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

BDD фокусируется на следующих вопросах:

• С чего начинается процесс.
• Что нужно тестировать, а что нет.
• Сколько проверок должно быть совершено за один раз.
• Что можно назвать проверкой.
• Как понять, почему тест не прошёл.

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

Как [роль того, чьи бизнес интересы удовлетворяются] я хочу, чтобы [описание функциональности так, как она должна работать], для того чтобы [описание выгоды].

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

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

Спецификация поведения строится в полуформальной форме. В настоящее время в практике BDD устоялась следующая структура:

1. Заголовок (англ. Title). В сослагательной форме должно быть дано описание бизнес-цели.
2. Описание (англ. Narrative). В краткой и свободной форме должны быть раскрыты следующие вопросы:
   1. Кто является заинтересованным лицом данной истории;
   2. Что входит в состав данной истории;
   3. Какую ценность данная история предоставляет для бизнеса.
3. Сценарии (англ. Scenarios). В одной спецификации может быть один и более сценариев, каждый из которых раскрывает одну из ситуаций поведения пользователя, тем самым конкретизируя описание спецификации. Каждый сценарий обычно строится по одной и той же схеме:
   1. Начальные условия (одно или несколько);
   2. Событие, которое инициирует начало этого сценария;
   3. Ожидаемый результат или результаты.

BDD не предоставляет каких-либо формальных правил, но настаивает на том, чтобы использовался ограниченный стандартный набор фраз, который включал бы все элементы спецификации поведения. В 2007 году Дэном Нортом был предложен шаблон для спецификации, который получил популярность и впоследствии стал известен как язык Gherkin^[1][2].

Основные фразы языка Gherkin представлены в следующей таблице.

Следующий пример демонстрирует спецификацию поведения с использованием языка Gherkin.

Story: Returns go to stock

As a store owner
In order to keep track of stock
I want to add items back to stock when they're returned.

Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When they return the black sweater for a refund
Then I should have four black sweaters in stock.

Scenario 2: Replaced items should be returned to stock
Given that a customer previously bought a blue garment from me
And I have two blue garments in stock
And three black garments in stock.
When they return the blue garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock.

История: Возвращённый товар должен быть учтён на складе

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

Сценарий 1: Возвращенные товары должны размещаться на складе
Дано то, что ранее покупатель приобрёл у меня чёрный свитер
И на моём складе уже есть три точно таких же.
Когда покупатель возвращает приобретенный свитер
Тогда я должен видеть, что сейчас на складе 4 чёрных свитера.

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

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

• Парсер может разбить спецификацию по её формальным частям, например по ключевым словам языка Gherkin. На выходе мы получаем набор предложений, каждое из которых начинается с ключевого слова.
• Каждое предложение может выражать один шаг теста.
• Некоторые части предложения могут являться входными параметрами, которые можно захватить, а остальные части могут никак не использоваться и служить только для понимания действия человеком. Обычно для такого захвата используется процессор регулярных выражений. Захваченные параметры могут быть переконвертированы и отправлены на вход конкретной исполняющей функции.

На этом принципе строятся такие фреймворки как JBehave и RBehave, которые основаны на языке Gherkin. Некоторые фреймворки строятся по аналогии, например CBehave и Cucumber.

Предположим, что мы разрабатываем движок для игры «Жизнь» и нам необходимо добавить возможность начальной расстановки живых клеток на поле. Пусть когда пользователь выбирает некоторую свободную точку поля, на ней появляется живая клетка. Если пользователь выбирает уже занятую клеткой точку поля, клетка исчезает, и точка поля становится свободной. Координаты поля вводятся в формате (x,y), где x — это номер точки по горизонтали, а y — номер точки по вертикали. Начало отсчета по обеим координатам начинается с верхнего левого угла, с единицы.

Опуская для простоты описание спецификации поведения, мы можем написать такой сценарий на языке Gherkin.

Given a 5 by 5 game
When I toggle the cell at (3, 4)
Then the grid should look like
 .....
 .....
 .....
 ..X..
 .....
When I toggle the cell at (3, 5)
Then the grid should look like
 .....
 .....
 .....
 ..X..
 ..X..
When I toggle the cell at (3, 4)
Then the grid should look like
 .....
 .....
 .....
 .....
 ..X..

Фреймворк JBehave написан на языке Java, следовательно тесты переводятся в код Java. Для фреймворка JBehave этот сценарий передаётся как обычный текстовый файл, который читается построчно. Всё что нужно разработчику, это предоставить функции, которые JBehave должен вызывать, когда он переходит на очередную строку. Для примера, реализация теста может быть такой:

private Game game;
private StringRenderer renderer;

@Given("a $width by $height game")
public void theGameIsRunning(int width, int height) {
    game = new Game(width, height);
    renderer = new StringRenderer();
    game.setObserver(renderer);
}
    
@When("I toggle the cell at ($column, $row)")
public void iToggleTheCellAt(int column, int row) {
    game.toggleCellAt(column, row);
}

@Then("the grid should look like $grid")
public void theGridShouldLookLike(String grid) {
    assertThat(renderer.asString(), equalTo(grid));
}

Для того чтобы однозначно сопоставлять функцию с предложением Gherkin, используются Java-аннотации, которые предоставляет фреймворк JBehave. Например, когда парсер движка доходит до любого из предложений типа

When I toggle the cell at (n, n)

движок JBehave по аннотации вычислит, что нужно вызвать метод

void iToggleTheCellAt(int column, int row)

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

• Carlos Solis, Xiaofeng Wang. Обзор концепции BDD (англ.) = A Study of the Characteristics of Behaviour Driven Development // IEEE 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications : сборник. — Oulu, Finland, 2011. — 3 November. — P. 383—387. — ISBN 978-1-4577-1027-8. — ISSN 1089-6503. — doi:10.1109/SEAA.2011.76.

• Bellware, Scott. Behavior-Driven Development (англ.). www.codemag.com. Дата обращения: 24 сентября 2018.
• Tharayil, Ranjith. Behavior-Driven Development: Simplifying the Complex Problem Space (англ.). www.solutionsiq.com (4 апреля 2018). Дата обращения: 24 сентября 2018.
• North, Dan. Introducing RBehave (англ.). dannorth.net (17 июня 2007). Дата обращения: 24 сентября 2018.
• Gherkin Reference (англ.). docs.cucumber.io. Дата обращения: 25 сентября 2018. Архивировано из оригинала 9 февраля 2019 года.