Поведенческая разработка

В программной инженерии разработка , управляемая поведением ( BDD ) - это гибкий процесс разработки программного обеспечения, который поощряет сотрудничество между разработчиками, QA и нетехническими или бизнес-участниками программного проекта. ^{[1] [2] [3]} Это побуждает команды использовать беседу и конкретные примеры, чтобы формализовать общее понимание того, как должно вести себя приложение. ^[4] Он возник в результате разработки через тестирование (TDD). ^{[1] [2] [5] [6] [ расплывчато ] [7]}Поведенческая разработка сочетает в себе общие методы и принципы TDD с идеями из предметно-ориентированного проектирования и объектно-ориентированного анализа и проектирования, чтобы предоставить командам разработчиков и менеджеров программного обеспечения общие инструменты и общий процесс для совместной разработки программного обеспечения. ^{[2] [7]}

Хотя BDD в основном представляет собой идею о том, как следует управлять разработкой программного обеспечения с учетом как деловых интересов, так и технических знаний, практика BDD предполагает использование специализированных программных инструментов для поддержки процесса разработки. ^[5] Хотя эти инструменты часто разрабатываются специально для использования в проектах BDD, их можно рассматривать как специализированные формы инструментов, поддерживающих разработку через тестирование. Инструменты служат для добавления автоматизации к вездесущему языку, который является центральной темой BDD.

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

История [ править ]

Разработка, управляемая поведением, является расширением разработки, управляемой тестированием : ^[9] разработка, которая использует простой предметно-ориентированный язык сценариев (DSL). Эти DSL преобразуют структурированные операторы естественного языка в исполняемые тесты. Результатом является более тесная связь с критериями приемлемости для данной функции и тестами, используемыми для проверки этой функциональности. Таким образом, это естественное расширение тестирования TDD в целом.

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

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

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

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

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

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

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

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

Принципы BDD [ править ]

Разработка через тестирование - это методология разработки программного обеспечения, которая, по сути, гласит, что для каждой единицы программного обеспечения разработчик программного обеспечения должен:

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

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

Разработка, управляемая поведением, определяет, что тесты любой единицы программного обеспечения должны быть определены с точки зрения желаемого поведения единицы. ^{[5] [7] [1]} Заимствуя гибкую разработку программного обеспечения, «желаемое поведение» в данном случае состоит из требований, установленных бизнесом, то есть желаемого поведения, которое имеет бизнес-ценность для любой организации, заказавшей строящуюся единицу программного обеспечения. . ^{[5] [1]} В практике BDD это упоминается как BDD как «внешняя-внутренняя» деятельность. ^[16]

Характеристики поведения [ править ]

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

BDD указывает, что бизнес-аналитики и разработчики должны сотрудничать в этой области и должны определять поведение в терминах пользовательских историй , каждая из которых явно записана в специальном документе. ^{[1] [16]} Каждая история пользователя должна каким-то образом иметь следующую структуру: ^{[5] [16]}

Заголовок

Явное название.

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

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

• Как : человек или роль, которые получат выгоду от функции;
• Я хочу : особенность;
• так что : выгода или ценность функции.

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

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

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

BDD не предъявляет никаких формальных требований к тому, как именно должны быть записаны эти пользовательские истории , но он настаивает, чтобы каждая команда, использующая BDD, придумала простой стандартизованный формат для записи пользовательских историй, который включает элементы, перечисленные выше. ^{[5] [16]} Однако в 2007 году Дэн Норт предложил шаблон для текстового формата, который нашел широкое распространение в различных программных инструментах BDD. ^[16] Краткий пример этого формата может выглядеть так:

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

В идеале сценарии формулируются декларативно, а не императивно - на деловом языке, без ссылки на элементы пользовательского интерфейса, через которые происходит взаимодействие. ^[17]

Этот формат называется языком Gherkin, синтаксис которого аналогичен приведенному выше примеру. Термин Gherkin , однако, относится к программным средствам Cucumber , JBehave, Lettuce ^[18] и Behat . ^{[19] [20] [21] [22]}

Спецификация как повсеместный язык [ править ]

Разработка, основанная на поведении, заимствует концепцию универсального языка из предметно-ориентированного дизайна . ^{[5] [7]} Вездесущий язык - это (полу) формальный язык, которым пользуются все члены команды разработчиков программного обеспечения - как разработчики программного обеспечения, так и нетехнический персонал. ^[23] Рассматриваемый язык используется и разрабатывается всеми членами команды как общее средство обсуждения предметной области программного обеспечения. ^[23] Таким образом, BDD становится средством связи между всеми различными ролями в программном проекте. ^{[5] [24]}

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

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

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

Специализированная поддержка инструментов [ править ]

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

Принципы работы с инструментами [ править ]

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

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

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

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

Примеры инструментов [ править ]

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

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

Рассмотрим реализацию Игры Жизни . Эксперт в предметной области (или бизнес-аналитик) может захотеть указать, что должно происходить, когда кто-то настраивает стартовую конфигурацию игровой сетки. Для этого он может захотеть привести пример ряда шагов, предпринятых человеком, переключающим ячейки. Пропустив повествовательную часть, он мог бы сделать это, написав следующий сценарий в текстовом документе (который является типом входного документа, который читает 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 );  renderer  =  новый  StringRenderer ();  игра . setObserver ( средство визуализации ); } @When ( "Я переключаю ячейку в ($ column, $ row)" ) public  void  iToggleTheCellAt ( int  column ,  int  row )  {  game . toggleCellAt ( столбец ,  строка ); }@Then ( "сетка должна выглядеть как $ grid" ) public  void  theGridShouldLookLike ( String  grid )  {  assertThat ( renderer . AsString (),  equalTo ( grid )); }

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

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

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

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

История против спецификации [ править ]

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

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

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

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

описать  хеш  делать  let ( : hash )  {  Hash [ : hello ,  'world' ]  } it  {  ожидать ( Hash . new ) . в  уравнение ({})  } он  "хеширует правильную информацию в ключе"  действительно  ожидает ( hash [ : hello ] ) . чтобы  eq ( 'world' )  конец он  «включает в себя ключ»  сделать  хэш . ключи . включают? ( : привет ) . должен  быть  настоящий  конец конец

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

Результатом проверки будет:

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

Три Амигоса [ править ]

Три Amigos, также называемые «Семинар по спецификациям», представляют собой встречу, на которой Владелец продукта обсуждает требование в форме «Спецификация на примере» с различными заинтересованными сторонами, такими как отдел контроля качества и команда разработчиков. Ключевая цель этого обсуждения - вызвать обсуждение и выявить любые недостающие спецификации. Обсуждение также дает платформу для QA, команды разработчиков и владельца продукта, чтобы сойтись и выслушать точки зрения друг друга, чтобы обогатить требования, а также убедиться, что они создают правильный продукт. ^[33]

Три Amigos

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

См. Также [ править ]

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

Ссылки [ править ]