Разработка, управляемая поведением - Введение

Разработка на основе поведения (BDD) - это процесс разработки программного обеспечения, изначально возникший из разработки, основанной на тестировании (TDD).

По словам Дэна Норта, ответственного за развитие BDD, «BDD использует примеры на нескольких уровнях, чтобы создать общее понимание и поверхностную неопределенность для предоставления программного обеспечения, которое имеет значение».

BDD использует примеры для иллюстрации поведения системы, написанные на читаемом и понятном языке для всех, кто участвует в разработке. Эти примеры включают -

Конвертируется в исполняемые спецификации.
Используется в качестве приемочных испытаний.

BDD - Ключевые особенности

Разработка, управляемая поведением, фокусируется на -

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

Происхождение BDD

Стоимость исправления дефекта увеличивается многократно, если дефект не обнаруживается в нужное время и не устраняется по мере его обнаружения. Рассмотрим следующий пример.

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

Потребность часа - это подход к развитию, который:

Основано на требованиях.
Ориентирован на требования на протяжении всей разработки.
Обеспечивает выполнение требований.

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

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

Практика BDD

Две основные практики BDD:

Спецификация на примере (SbE)
Разработка через тестирование (TDD)

Спецификация на примере

Спецификация на примере (SbE) использует примеры в беседах, чтобы проиллюстрировать бизнес-правила и поведение создаваемого программного обеспечения.

Спецификация на примере позволяет владельцам продуктов, бизнес-аналитикам, тестировщикам и разработчикам устранить распространенные недопонимания в отношении бизнес-требований.

Разработка через тестирование

Разработка через тестирование в контексте BDD превращает примеры в удобочитаемые исполняемые спецификации.

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

Гибкий BDD

В Agile-разработке программного обеспечения метод BDD используется для достижения общего понимания ожидаемых спецификаций.

Следующие шаги выполняются в Agile BDD -

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

Agile Manifesto и BDD

В Agile Manifesto говорится следующее:

Мы открываем лучшие способы разработки программного обеспечения, занимаясь этим и помогая в этом другим. Благодаря этой работе мы пришли к выводу:

Individuals and interactions - над Процессами и инструментами
Working software - Более подробная документация
Customer collaboration - по переговорам по контракту
Responding to change - более Следуя плану

То есть, хотя предметы справа имеют ценность, мы ценим предметы слева больше.

BDD присоединяется к манифесту Agile следующим образом:

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