Электромонтаж Ремонт и отделка Укладка напольных покрытий, теплые полы Тепловодоснабжение

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


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

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

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

Описание

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

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

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

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

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

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

Принципы BDD

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

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

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

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

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

    Способы реализации 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 фреймворков


    Имя:*
    E-Mail:
    Комментарий: