WikiSort.ru - Не сортированное

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

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

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

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

Описание

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

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

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

Исходя из этих вопросов, 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 концепции

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

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

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

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..

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));
}

When I toggle the cell at (n, n)

void iToggleTheCellAt(int column, int row)

Литература

• 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 April 2018). Проверено 24 сентября 2018.
• North, Dan. Introducing RBehave (англ.). dannorth.net (17 June 2007). Проверено 24 сентября 2018.
• Gherkin Reference (англ.). docs.cucumber.io. Проверено 25 сентября 2018.