Развитие, основанное на поведении

Разработка, управляемая поведением ( BDD ), включает в себя наименование тестов программного обеспечения с использованием языка предметной области для описания поведения кода .

BDD предполагает использование предметно-ориентированного языка (DSL) с использованием конструкций естественного языка (например, предложений, подобных английскому), которые могут выражать поведение и ожидаемые результаты.

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

BDD считается усовершенствованием разработки через тестирование (TDD). BDD сочетает в себе методы TDD с идеями предметно-ориентированного проектирования и объектно-ориентированного анализа и проектирования, чтобы предоставить группам разработки и управления ПО общие инструменты и общий процесс для совместной разработки программного обеспечения.

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

Обзор

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

Таким образом, BDD является расширением TDD.

BDD фокусируется на:

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

По своей сути BDD — это переосмысление подхода к автоматизированному тестированию (включая модульное тестирование и приемочное тестирование ), чтобы избежать проблем, которые возникают естественным образом. Например, BDD предлагает, чтобы имена модульных тестов представляли собой целые предложения, начинающиеся с условного глагола («следует» на английском языке, например), и записывались в порядке бизнес-ценности. Приемочные тесты должны быть написаны с использованием стандартной гибкой структуры пользовательской истории : «Будучи [роль/действующее лицо/заинтересованное лицо] я хочу, чтобы [функция/возможность] приносила [выгоду]». Критерии приемки должны быть написаны в виде сценариев и реализованы в классах: учитывая [исходный контекст], когда [происходит событие], затем [обеспечивайте некоторые результаты] .

Начиная с этого момента, многие люди в течение многих лет разрабатывали BDD-фреймворки, наконец, превратив их в среду общения и сотрудничества для разработчиков, специалистов по обеспечению качества и нетехнических или бизнес-участников программного проекта. Во время «Agile-спецификаций, BDD и обмена тестированием» в ноябре 2009 года в Лондоне Дэн Норт дал следующее описание BDD:

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

История

Во время интервью с Дэном Нортом на конференции GOTO в 2013 году Лиз Кио определил BDD как:

Он использует примеры, чтобы объяснить, как ведет себя приложение... И обсуждает эти примеры.

Дэн Норт создал структуру BDD JBehave , за которой последовала платформа BDD уровня истории для Ruby под названием RBehave. который позже был интегрирован в проект RSpec . Он также работал с Дэвидом Челимски, Аслаком Хеллесой и другими над разработкой RSpec, а также над написанием «Книги RSpec: Разработка, основанная на поведении, с RSpec, Cucumber и друзьями». Первый сюжетно-ориентированный фреймворк в RSpec позже был заменен Cucumber , разработанным в основном Аслаком Хеллесой . Capybara , которая является частью среды тестирования Cucumber, является одним из таких веб-программ для автоматизации тестирования.

Принципы

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

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

Поведенческие

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

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

Заголовок

Явный заголовок.

Повествование

Краткий вводный раздел со следующей структурой:

• Как : человек или роль, которая выиграет от этой функции;
• Я хочу : функцию;
• так что : польза или ценность функции.

Критерии приемки

Описание каждого конкретного сценария повествования со следующей структурой:

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

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

Название  : Возврат и обмен учитываются в инвентаре. 

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

  Сценарий 1.  Товары, возвращенные для возврата, должны быть добавлены в инвентарь. 
  Учитывая  , что клиент ранее купил у меня черный свитер 
  и  у меня в инвентаре три черных свитера, 
  когда  они вернут черный свитер для возврата денег, 
  тогда  у меня в инвентаре должно быть четыре черных свитера. 

  Сценарий 2:  Обмененные предметы следует вернуть в инвентарь. 
  Учитывая  , что покупатель ранее купил у меня синюю одежду. 
  и  у меня в инвентаре есть два синих предмета одежды 
  и  три чёрных предмета одежды в инвентаре, 
  когда  они меняют синюю одежду на черную одежду, 
  тогда  у меня в инвентаре должно быть три синих предмета одежды 
  и  две черные одежды в инвентаре. 
 

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

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

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

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

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

Приведенный выше пример устанавливает пользовательскую историю для разрабатываемой программной системы. Эта пользовательская история определяет заинтересованную сторону, бизнес-эффект и ценность бизнеса. В нем также описывается несколько сценариев, каждый из которых имеет предварительное условие, триггер и ожидаемый результат. Каждая из этих частей точно идентифицируется более формальной частью языка (например, термин «Дано» можно рассматривать как ключевое слово ) и, следовательно, может быть каким-то образом обработана инструментом, который понимает формальные части вездесущего языка.

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

Специализированный инструмент

Как и TDD, BDD может включать использование специализированных инструментов.

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

Принципы оснастки

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

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

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

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

Примеры инструментов

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

Вероятно, самым известным является JBehave, разработанный Дэном Нортом, Элизабет Кио и некоторыми другими. Ниже приведен пример, взятый из этого проекта:

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

Учитывая  игру 5 на 5 
  Когда  я переключаю ячейку на (3, 2) 
  Тогда  сетка должна выглядеть так 
  ..... 
  ..... 
  ..... 
  ..ИКС.. 
  ..... 
  Когда  я переключаю ячейку на (3, 1) 
  Тогда  сетка должна выглядеть так 
  ..... 
  ..... 
  ..... 
  ..ИКС.. 
  ..ИКС.. 
  Когда  я переключаю ячейку на (3, 2) 
  Тогда  сетка должна выглядеть так 
  ..... 
  ..... 
  ..... 
  ..... 
  ..ИКС.. 
 

Жирный шрифт не является частью ввода; он включен сюда, чтобы показать, какие слова признаются формальным языком. JBehave распознает термины «Дано » (как предварительное условие, определяющее начало сценария), « Когда » (как триггер события) и «Тогда» (как постусловие, которое должно быть проверено как результат действия, следующего за триггером). Основываясь на этом, JBehave способен читать текстовый файл, содержащий сценарий, и разбирать его на предложения (предложение настройки, а затем три триггера событий с проверяемыми условиями). Затем JBehave берет эти предложения и передает их коду, который способен устанавливать тест, реагировать на триггеры событий и проверять результат. Этот код должен быть написан разработчиками из команды проекта (на Java , поскольку именно на этой платформе основан JBehave). В этом случае код может выглядеть так:

частная   игра   ; игра  ; 
  частный   StringRenderer   рендерер  ; 

  @Given  (  «игра $ширина на $высоту»  ) 
 public   void   theGameIsRunning  (  int   width  ,   int   height  )   { 
     game   =   new   Game  (  width  ,   height  ); 
      рендерер   =   новый   StringRenderer  (); 
      игра  .   setObserver  (  рендерер  ); 
  } 
    
 @When  (  «Я переключаю ячейку в ($column, $row)»  ) 
 public   void   iToggleTheCellAt  (  int   columns  ,   int   row  )   { 
     game  .   toggleCellAt  (  столбец  ,   строка  ); 
  } 

 @Then  (  «сетка должна выглядеть как $grid»  public 
 void   theGridShouldLookLike   (  Stringgrid  )   )  {   assertThat 
     (  renderer  .  asString  (  ),   equalTo  (  grid  )); 
  } 

В коде есть метод для каждого типа предложения в сценарии. JBehave определит, какой метод соответствует какому предложению, с помощью аннотаций и будет вызывать каждый метод по порядку во время выполнения сценария. Ожидается, что текст в каждом предложении сценария будет соответствовать тексту шаблона, указанному в коде для этого предложения (например, ожидается, что за заданным в сценарии последует предложение в форме «игра X по Y»). . JBehave поддерживает сопоставление предложений с шаблонами и имеет встроенную поддержку выбора терминов из шаблона и передачи их методам тестового кода в качестве параметров. Тестовый код обеспечивает реализацию каждого типа предложения в сценарии, который взаимодействует с тестируемым кодом и выполняет тест на основе сценария. В этом случае:

• The theGameIsRunning Метод реагирует на предложение Give , настраивая начальную сетку игры.
• The iToggleTheCellAt Метод реагирует на предложение When , запуская событие переключения, описанное в предложении.
• The theGridShouldLookLike Метод реагирует на предложение then , сравнивая состояние игровой сетки с ожидаемым состоянием сценария.

Основная функция этого кода — быть мостом между текстовым файлом с историей и тестируемым кодом. Обратите внимание, что тестовый код имеет доступ к тестируемому коду (в данном случае экземпляру Game) и очень прост по своей природе. Код теста должен быть простым, иначе разработчику придется писать тесты для своих тестов.

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

против

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

Спецификация:  Стек 

  Когда  создается новый стек 
  Тогда  там пусто 

  Когда  элемент добавляется в стек 
  Тогда  этот элемент находится на вершине стека 

  Когда  в стеке N элементов  
  И  элемент E находится на вершине стека 
  Затем  операция pop возвращает E 
  И  новый размер стека — N-1. 
 

Такая спецификация может точно определять поведение тестируемого компонента, но она менее значима для бизнес-пользователя. В результате тестирование на основе спецификаций рассматривается в практике BDD как дополнение к тестированию на основе историй и работает на более низком уровне. Тестирование спецификаций часто рассматривается как замена модульного тестирования в свободном формате.

Инструменты тестирования спецификаций, такие как RSpec и JDave, по своей природе несколько отличаются от таких инструментов, как JBehave. Поскольку они рассматриваются как альтернатива базовым инструментам модульного тестирования, таким как JUnit , эти инструменты склонны отказываться от разделения истории и кода тестирования и вместо этого предпочитают встраивать спецификацию непосредственно в тестовый код. Например, тест RSpec для хеш-таблицы может выглядеть так:

описать   Хэш   do 
   let  (  :hash  )   {   Hash  [  hello  ,   'world  ]   } 

   it   {   ожидать  (  Hash.new  :  '  )  .   to   eq  ({})   } 

   он   «хэширует правильную информацию в ключе»,   ( 
     ожидаем  hash  [  :  hello  ]  )  .   to   eq  (  'world'  ) 
   end 

   it   'includes key'   do 
     hash  .   ключи  .   включать?   (  :привет  )  .   должно   быть   правдой, 
   конец 
 , конец 

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

Результатом теста будет:

Хэш
    должно быть уравнение {}
    включает ключ
    хэширует правильную информацию в ключе
 

Три друга

Три амиго, также называемые «семинар по спецификациям», — это встреча, на которой владелец продукта обсуждает требования в форме спецификации на примере с различными заинтересованными сторонами, такими как команда контроля качества и команда разработчиков. Основная цель этого обсуждения — вызвать разговор и выявить недостающие спецификации. Обсуждение также предоставляет платформу для QA, команды разработчиков и владельца продукта, чтобы они могли встретиться и выслушать точки зрения друг друга, чтобы обогатить требования, а также убедиться, что они создают правильный продукт.

Три амиго:

• Бизнес. Роль бизнес-пользователя состоит только в том, чтобы определить проблему, а не предлагать решение.
• Разработка. Роль разработчиков заключается в предложении способов решения проблемы.
• Тестирование. Роль тестировщиков состоит в том, чтобы подвергнуть сомнению решение, предложить как можно больше различных возможностей для мозгового штурма через сценарии «что, если» и помочь сделать решение более точным для устранения проблемы.

См. также

• Спецификация на примере
• Поведение (инфраструктура PHP)
• Структура среды обитания
• Согласие (фреймворк Java)
• Датчик (программное обеспечение)
• Жасмин (среда тестирования JavaScript)
• Squish GUI Tester (инструмент тестирования BDD GUI для JavaScript, Python, Perl, Ruby и Tcl)
• Вариант использования