Введение

Наименование программных тестов

Разработка на основе поведения (BDD) предполагает наименование программных тестов с использованием языка предметной области для описания поведения кода. BDD включает использование языка, специфичного для предметной области (DSL), использующего конструкции естественного языка (например, предложения, похожие на английские), которые могут выражать поведение и ожидаемые результаты. Сторонники утверждают, что это способствует сотрудничеству между разработчиками, специалистами по обеспечению качества и представителями заказчика в программном проекте. BDD поощряет команды использовать обсуждения и конкретные примеры для формализации общего понимания того, как приложение должно функционировать. BDD считается эффективной практикой, особенно когда область решаемых задач сложна. BDD рассматривается как усовершенствование разработки через тестирование (TDD). BDD объединяет методы TDD с идеями из предметно-ориентированного проектирования и объектно-ориентированного анализа и проектирования, чтобы предоставить командам разработки и управления программным обеспечением общие инструменты и единый процесс для совместной разработки программного обеспечения. В ноябре 2009 года на конференции "Agile specifications, BDD and Testing eXchange" в Лондоне Дэн Норт дал следующее описание BDD:
BDD – это методология второго поколения, основанная на подходе "извне внутрь", "pull-based", с участием множества заинтересованных сторон, масштабируемая, с высокой степенью автоматизации и гибкая. Она описывает цикл взаимодействий с четко определенными результатами, приводящий к поставке рабочего, протестированного программного обеспечения, которое имеет ценность.

Принципы

BDD предполагает, что названия программных тестов должны отражать желаемое поведение. Каждая пользовательская история в определенной степени должна соответствовать следующей структуре:

Этот формат известен как язык Gherkin. Однако термин Gherkin специфичен для программных инструментов Cucumber, JBehave, Lettuce, behave и Behat.

Спецификация как вездесущий язык

BDD заимствует концепцию вездесущего языка из предметно-ориентированного проектирования. Этот язык используется и разрабатывается всеми членами команды как общий способ обсуждения предметной области разрабатываемого программного обеспечения. Распространенным риском при разработке программного обеспечения является нарушение коммуникации между разработчиками и бизнес-заказчиками. BDD использует спецификацию желаемого поведения в качестве вездесущего языка для членов проектной команды. Именно поэтому BDD настаивает на полуформальном языке для поведенческой спецификации: определенная формальность необходима для того, чтобы язык был вездесущим. Эта модель также лежит в основе различных программных инструментов, поддерживающих BDD. Приведенный выше пример иллюстрирует пользовательскую историю для разрабатываемой программной системы. Эта пользовательская история определяет заинтересованную сторону, бизнес-эффект и бизнес-ценность. В ней также описано несколько сценариев, каждый из которых включает предварительное условие, триггер и ожидаемый результат. Каждая из этих частей четко идентифицируется более формальной частью языка (например, термин Given может рассматриваться как ключевое слово) и, следовательно, может быть обработана инструментом, понимающим формальные элементы вездесущего языка. Большинство приложений BDD используют текстовые DSL и подходы к спецификации. Однако графическое моделирование сценариев интеграции также успешно применяется на практике, например, для целей тестирования.

Специализированное оборудование

Как и TDD, BDD может включать использование специализированных инструментов. BDD требует не только тестового кода, как и TDD, но и документа, описывающего поведение на более понятном для человека языке. Это требует двухэтапного процесса для выполнения тестов: чтения и разбора описаний, а затем чтения тестового кода и поиска соответствующей реализации для выполнения. Этот процесс делает BDD более трудоемким для разработчиков. Сторонники утверждают, что благодаря своей удобочитаемости ценность этих документов распространяется на нетехническую аудиторию и может служить средством коммуникации для описания требований ("фич").

Принципы инструмента

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

Инструмент считывает документ спецификации. Он напрямую интерпретирует полностью формальные части единого языка (например, ключевое слово Given, как в приведенном выше примере). На основе этого инструмент разбивает каждый сценарий на осмысленные фрагменты. Каждый отдельный фрагмент сценария преобразуется в параметр для теста пользовательской истории. Эта часть требует специфической работы от разработчиков программного обеспечения. Затем фреймворк выполняет тест для каждого сценария, используя параметры из этого сценария. Дэн Норт разработал ряд фреймворков, поддерживающих BDD (включая JBehave и RBehave), принцип работы которых основан на шаблоне, предложенном им для записи пользовательских историй.