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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ • Проектирование • Программирование • Конструирование • Тестирование • Отладка • Развёртывание • Сопровождение • Документирование
Парадигмы и модели
Agile • Cleanroom • Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
ASD • DevOps • DAD • DSDM • FDD • Канбан • Lean SD • LeSS • MDD • MSF • PSP • OpenUP • RAD • RUP • SAFe • Scrum • TSP • UP • XP
Инструменты
Компилятор • Отладчик • Профилирование • GUI-конструктор • ИСР • Автоматизация сборки • Автоматизация релиза • Инструменты тестирования

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
(Feature[3])
История Каждая новая спецификация начинается с этого ключевого слова, после которого через двоеточие в сослагательной форме пишется имя истории.
As a Как (в роли) Роль того лица в бизнес-модели, которому данная функциональность интересна.
In order to Чтобы достичь В краткой форме какие цели преследует лицо.
I want to Я хочу, чтобы В краткой форме описывается конечный результат.
Scenario Сценарий Каждый сценарий одной истории начинается с этого слова, после которого через двоеточие в сослагательной форме пишется цель сценария. Если сценариев в одной истории несколько, то после ключевого слова должен писаться его порядковый номер.
Given Дано Начальное условие. Если начальных условий несколько, то каждое новое условие добавляется с новой строки с помощью ключевого слова And.
When Когда (прим.: что-то происходит) Событие, которое инициирует данный сценарий. Если событие нельзя раскрыть одним предложением, то все последующие детали раскрываются через ключевые слова And и But.
Then Тогда Результат, который пользователь должен наблюдать в конечном итоге. Если результат нельзя раскрыть одним предложением, то все последующие детали раскрываются через ключевые слова And и But.
And И Вспомогательное ключевое слово, аналог конъюнкции.
But Но Вспомогательное ключевое слово, аналог отрицания.

Следующий пример демонстрирует спецификацию поведения с использованием языка 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.

Реализация на примере JBehave[править | править код]

Предположим, что мы разрабатываем движок для игры «Жизнь» и нам необходимо добавить возможность начальной расстановки живых клеток на поле. Пусть когда пользователь выбирает некоторую свободную точку поля, на ней появляется живая клетка. Если пользователь выбирает уже занятую клеткой точку поля, клетка исчезает и точка поля становится свободной. Координаты поля вводятся в формате (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.

Примеры BDD фреймворков[править | править код]

C/C++
  • Catch
  • CBehave
Ruby
  • RBehave
  • RSpec
Python
.NET
  • NBehave
  • MSpec / Machine.Specifications
  • Specflow
  • Pickles
  • Concordion.NET
  • FSpec
  • NaturalSpec
  • TickSpec
  • SubSpec
Java
  • JBehave
  • Jnario
  • JGiven
JavaScript / TypeScript
  • Jasmine
Lua
  • Busted
Perl
  • Test::BDD::Cucumber[8]
  • Test::Cucumber::Tiny[9]
  • Test::Cukes[10]
  • Test::Pcuke[11]
PHP
  • Behat
  • Codeception
Go
  • Ginkgo
Кроссплатформенные
  • Cucumber
  • Squish
  • Yulup

Литература[править | править код]

Примечания[править | править код]

  1. North.
  2. Строго говоря, Gherkin это язык спецификации поведения для BDD фреймворка Cucumber, однако ввиду того, что этот фреймворк популярен, всё что похоже на эту спецификацию называют Gherkin.
  3. Cucumber. Gherkin Reference.
  4. Behave documentation. MetaCPAN (26 февраля 2019). Дата обращения 26 февраля 2019.
  5. Lettuce python bdd framework. MetaCPAN (26 февраля 2019). Дата обращения 26 февраля 2019.
  6. Radish framework - python bdd framework. MetaCPAN (26 февраля 2019). Дата обращения 26 февраля 2019.
  7. Robot framework - python bdd framework. MetaCPAN (26 февраля 2019). Дата обращения 26 февраля 2019.
  8. Test::BDD::Cucumber - Feature-complete Cucumber-style testing in Perl. MetaCPAN (21 апреля 2018). Дата обращения 1 ноября 2018.
  9. Test::Cucumber::Tiny - Cucumber-style testing in perl. MetaCPAN (14 февраля 2014). Дата обращения 1 ноября 2018.
  10. Test::Cukes - A BBD test tool inspired by Cucumber. MetaCPAN (12 декабря 2010). Дата обращения 1 ноября 2018.
  11. Test::Pcuke::Manual - is a proto manual for Test::Pcuke package. MetaCPAN (3 декабря 2011). Дата обращения 1 ноября 2018.

Ссылки[править | править код]