Behavior-Driven Development

Вольный перевод статьи: Behavior-Driven Development — Scaled Agile Framework.

Это именно то, о чем я просил, но не то, что я хочу

Поэма «Ночь перед воплощением», автор неизвестен

Разработка на основе поведения (Behavior-Driven Development, BDD) — это практика Agile-тестирования, когда в первую очередь проводятся проверочные испытания, которые обеспечивают встроенное качество за счет определения (и, потенциально, автоматизации) тестов до или как часть определения поведения системы. BDD — это совместный процесс, который создает общее понимание требований между бизнесом и Agile-командами. Его цель — помочь в управлении разработкой, уменьшить количество переделок и увеличить поток. Не фокусируясь на внутренней реализации, тесты BDD представляют собой бизнес-сценарии, которые пытаются описать поведение пользователя с точки зрения Истории (Story), Фичи (Feature) или Возможности (Capability).

Будучи автоматизированными, эти тесты гарантируют, что система постоянно соответствует заданному поведению даже в процессе своего развития. Это, в свою очередь, позволяет выпускать Релиз по Потребности (Release on Demand). Автоматизированные тесты BDD могут также служить для формулирования поведения системы, в качестве встроенной в другую систему.

Как определить будущее поведение системы

При разработке инновационных систем сложно точно определить, что именно нужно создать. Кроме того, новые идеи трудно донести до широкого круга заинтересованных лиц, ответственных за внедрение системы. На рис. 1 показаны три точки зрения (называемые триадой), необходимые, для четкого определения поведения решения:

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

Рис. 1. Разнообразие восприятий, необходимое для определения объективного принятия решения

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

Процесс поведенческой разработки

Процесс BDD проходит три этапа — исследование (discovery: раскрытие проблемы клиента и ее решения), формулирование и автоматизация — где критерии приемки преобразуются в приемочные испытания, которые затем автоматизируются. Процесс начинается на этапе исследования, когда Владелец Продукта (Product Owner, РО) или Менеджер Продукта (Product Manager, PM) создает критерии приемки как часть написания Истории или Фичи. Процесс исследования является совместным, и члены команды также определяют и вносят дополнительные критерии.

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

На этапе автоматизации приемочные тесты автоматизируются, поэтому они могут проводиться непрерывно и проверять, что система всегда поддерживает актуальное поведение.

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

• поведенческая разработка (BDD);
• разработка на основе приемочных испытаний (Acceptance Test-Driven Development, ATDD);
• спецификация на примере (Specification By Example, SBE).

В подходах существуют небольшие различия, но все они подчеркивают необходимость понимания требований до их реализации.

Пример

Описание поведения начинается с Истории, Фичи или Возможности, указанных в критериях приемки. Все они определяются с использованием клиентских терминов, а не внедрения. Вот пример истории и критерии ее принятия:

Рис. 2. Пример истории и критерии приёмки

Критерии приёмки также могут быть записаны в формате «Given—When—Then» (GWT), как показано ниже:

Given (Дано) ограничение скорости

When (Когда) машина едет

Then (Тогда) скорость близка к предельной, но не выше.

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

Дано ограничение скорости — 80 км/ч

Когда машина едет

Тогда её скорость — от 78 до 80 км/ч.

В сотрудничестве с командой (триадой) появятся дополнительные критерии приёмки и сценарии, например: когда ограничение скорости меняется, скорость резко не меняется.

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

Дано ограничение скорости составляет 80 км/ч

Когда ограничение скорости изменяется до 50 км/ч

Тогда скорость должна снижаться менее чем на 5 км/ч за сек.

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

Рис. 3. Процесс BDD детализирует поведенческие характеристики.

Автоматизация приемочных тестов

Автоматизация этих бизнес-тестов является важной причиной по использованию формата «Дано—Когда—Тогда» (GWT — Given—When—Then). Для поддержки этого синтаксиса можно использовать такие инструменты как Cucumber и Framework for Integrated Testing (FIT) . Для поддержки тестирования регрессии непрерывной поставки тесты должны быть по возможности автоматизированы.

Приемочные тесты Истории пишутся и выполняются в той же итерации, что и разработка кода. Если История не проходит тесты, История не засчитывается команде. У Фич и возможностей есть свои собственные приемочные тесты, которые показывают, как несколько Историй работают вместе в более широком контексте. Как правило, эти тесты демонстрируют поведение более крупных сценариев рабочего процесса и должны выполняться во время итерации, в которой Фича или возможность завершены.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.