Behavior Driven Development (BDD) — это процесс разработки программного обеспечения, который первоначально возник из Test Driven Development (TDD).
По словам Дэна Норта, ответственного за развитие BDD, «BDD использует примеры на разных уровнях для создания общего понимания и поверхностной неопределенности для предоставления программного обеспечения, которое имеет значение».
BDD использует примеры, иллюстрирующие поведение системы, написанные понятным и понятным языком для всех, кто участвует в разработке. Эти примеры включают в себя —
-
Преобразован в исполняемые спецификации.
-
Используется в качестве приемочных испытаний.
Преобразован в исполняемые спецификации.
Используется в качестве приемочных испытаний.
BDD — Ключевые особенности
Behavior Driven Development фокусируется на —
-
Предоставление общего процесса и общих инструментов, способствующих коммуникации для разработчиков программного обеспечения, бизнес-аналитиков и заинтересованных сторон для совместной работы над разработкой программного обеспечения с целью предоставления продукта с деловой ценностью.
-
Что должна делать система, а не то, как она должна быть реализована.
-
Обеспечение лучшей читаемости и видимости.
-
Проверка не только работы программного обеспечения, но и того, что оно соответствует ожиданиям клиента.
Предоставление общего процесса и общих инструментов, способствующих коммуникации для разработчиков программного обеспечения, бизнес-аналитиков и заинтересованных сторон для совместной работы над разработкой программного обеспечения с целью предоставления продукта с деловой ценностью.
Что должна делать система, а не то, как она должна быть реализована.
Обеспечение лучшей читаемости и видимости.
Проверка не только работы программного обеспечения, но и того, что оно соответствует ожиданиям клиента.
Происхождение БДД
Стоимость исправления дефекта увеличивается в несколько раз, если дефект не обнаружен в нужное время и исправлен по мере обнаружения. Рассмотрим следующий пример.
Это показывает, что, если требования не получены правильно, было бы дорого исправлять дефекты, возникающие из-за неправильного понимания требований на более позднем этапе. Кроме того, конечный продукт может не соответствовать ожиданиям клиента.
Необходимость часа — это подход к развитию, который —
-
Основано на требованиях.
-
Ориентирован на требования на протяжении всей разработки.
-
Гарантирует, что требования выполнены.
Основано на требованиях.
Ориентирован на требования на протяжении всей разработки.
Гарантирует, что требования выполнены.
Подход разработки, который может заботиться о вышеупомянутых требованиях, является BDD. Таким образом, развитие, управляемое поведением —
-
Получает примеры различных ожидаемых поведений системы.
-
Позволяет писать примеры на языке, используя термины бизнес-домена, чтобы обеспечить простоту понимания для всех, кто участвует в разработке, включая клиентов.
-
Получает примеры, утверждаемые время от времени с помощью разговоров.
-
Ориентирован на требования заказчика (примеры) на протяжении всей разработки.
-
Использует примеры в качестве приемочных испытаний.
Получает примеры различных ожидаемых поведений системы.
Позволяет писать примеры на языке, используя термины бизнес-домена, чтобы обеспечить простоту понимания для всех, кто участвует в разработке, включая клиентов.
Получает примеры, утверждаемые время от времени с помощью разговоров.
Ориентирован на требования заказчика (примеры) на протяжении всей разработки.
Использует примеры в качестве приемочных испытаний.
BDD Практики
Две основные практики BDD —
-
Спецификация по примеру (SbE)
-
Разработка через тестирование (TDD)
Спецификация по примеру (SbE)
Разработка через тестирование (TDD)
Спецификация примером
Спецификация путем примера (SbE) использует примеры в разговорах, чтобы проиллюстрировать бизнес-правила и поведение программного обеспечения, которое будет построено.
Specification by Example позволяет владельцам продуктов, бизнес-аналитикам, тестировщикам и разработчикам устранять распространенные недоразумения относительно бизнес-требований.
Разработка через тестирование
Разработка через тестирование в контексте BDD превращает примеры в удобочитаемые, исполняемые спецификации.
Разработчики используют эти спецификации в качестве руководства для реализации новых функций. Это приводит к обедненной кодовой базе и ряду автоматических регрессионных тестов, которые поддерживают низкие затраты на обслуживание в течение всего срока службы программного обеспечения.
Agile BDD
В гибкой разработке программного обеспечения используется метод BDD, чтобы прийти к общему пониманию ожидающих рассмотрения спецификаций.
Следующие шаги выполняются в Agile BDD —
-
Разработчики и владелец продукта совместно пишут ожидающие спецификации в текстовом редакторе.
-
Владелец продукта указывает поведение, которое они ожидают от системы.
-
Разработчики
-
Заполните спецификации этими подробностями поведения.
-
Задайте вопросы, основанные на их понимании системы.
-
-
Считается, что текущее поведение системы позволяет увидеть, не нарушит ли новая функция какие-либо из существующих функций.
Разработчики и владелец продукта совместно пишут ожидающие спецификации в текстовом редакторе.
Владелец продукта указывает поведение, которое они ожидают от системы.
Разработчики
Заполните спецификации этими подробностями поведения.
Задайте вопросы, основанные на их понимании системы.
Считается, что текущее поведение системы позволяет увидеть, не нарушит ли новая функция какие-либо из существующих функций.
Agile Manifesto и BDD
Agile Manifesto гласит следующее:
Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к оценке —
-
Индивидуумы и взаимодействия — над процессами и инструментами
-
Рабочее программное обеспечение — более полная документация
-
Взаимодействие с клиентами — более договорные переговоры
-
Реагирование на изменения — по плану
Индивидуумы и взаимодействия — над процессами и инструментами
Рабочее программное обеспечение — более полная документация
Взаимодействие с клиентами — более договорные переговоры
Реагирование на изменения — по плану
То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.
BDD присоединяется к манифесту Agile следующим образом: