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

Наименование теста программного обеспечения

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

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

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

BDD считается усовершенствованием разработки через тестирование (TDD). ^[1]^[5]^[6]^{[ неопределенно ]}^[7] ^[8] BDD сочетает в себе методы TDD с идеями проектирования на основе предметной области и объектно-ориентированного анализа и проектирования, чтобы предоставить группам разработки и управления ПО общие инструменты и общий процесс для совместной разработки ПО. ^[1]^[7]

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

Обзор

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

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

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

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

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

Начиная с этого момента, многие люди в течение многих лет разрабатывали фреймворки BDD, в конечном итоге сформулировав их как фреймворк для общения и совместной работы разработчиков, QA и нетехнических или деловых участников программного проекта. ^[9]

Принципы

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

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

Поведенческие характеристики

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

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

Заголовок: Явное название.

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

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

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

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

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

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

BDD не требует, как форматируется эта информация, но предполагает, что команда должна выбрать относительно простой стандартизированный формат с указанными выше элементами. ^[5] Он также предполагает, что сценарии должны быть сформулированы декларативно, а не императивно — на деловом языке, без ссылок на элементы пользовательского интерфейса, через которые происходит взаимодействие. ^[10] Этот формат упоминается в Cucumber как язык Gherkin .

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

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

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

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

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

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

Подобно TDD, BDD может подразумевать использование специализированных инструментов.

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

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

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

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

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

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

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

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

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

Три амиго

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

Эти три друга:

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

Смотрите также

Спецификация по примеру
Behat (фреймворк PHP)
Фреймворк Cynefin
Concordion (Java-фреймворк)
RSpec
Измерять
Jasmine (фреймворк тестирования JavaScript)
Squish GUI Tester (инструмент тестирования BDD GUI для JavaScript, Python, Perl, Ruby и Tcl)
Вариант использования
Fitnesse использовался для развертывания BDD ^[18]

Ссылки

^ abc "Behaviour-Driven Development". Архивировано из оригинала 1 сентября 2015 года . Получено 12 августа 2012 года .
^ Keogh, Liz (2009-09-07). "Введение в развитие, основанное на поведении". SkillsMatterr . Архивировано из оригинала 2021-02-25 . Получено 1 мая 2019 .
^ Джон Фергюсон Смарт (2014). BDD в действии: разработка на основе поведения для всего жизненного цикла программного обеспечения . Manning Publications. ISBN 9781617291654.
^ Tharayil, Ranjith (15 февраля 2016 г.). «Развитие, основанное на поведении: упрощение пространства сложных проблем». SolutionsIQ . Получено 15 февраля 2018 г.
^ abcdefghij Харинг, Рональд (февраль 2011 г.). де Рюитер, Роберт (ред.). «Разработка, основанная на поведении: лучше, чем разработка, основанная на тестировании». Журнал Java (на голландском языке) (1). Журналы Veen: 14–17 . ISSN 1571-6236.
^ Солис, Карлос; Ван, Сяофэн (2011). «Исследование характеристик разработки, основанной на поведении». 2011 37-я конференция EUROMICRO по программной инженерии и передовым приложениям . С. 383–387 . doi :10.1109/SEAA.2011.76. hdl : 10344/1256 . ISBN 978-1-4577-1027-8. S2CID 3392536.
^ abcd Bellware, Scott (июнь 2008 г.). «Behavior-Driven Development». Code Magazine . Архивировано из оригинала 12 июля 2012 г. Получено 1 мая 2019 г.
↑ Лиз Кеог (27 июня 2011 г.). «ATDD против BDD и краткая история некоторых связанных с этим вещей» . Получено 6 мая 2019 г.
^ "Книга RSpec – Вопрос о главе 11: Написание важного программного обеспечения". Архивировано из оригинала 2009-11-07 . Получено 2009-08-09 .
^ Мейби, Бен. "Императивные и декларативные сценарии в пользовательских историях". Архивировано из оригинала 3 июня 2010 г. Получено 19 мая 2008 г.
^ Эванс, Эрик (2003). Проектирование на основе предметной области: борьба со сложностью в самом сердце программного обеспечения. Addison-Wesley. ISBN 978-0-321-12521-7. Получено 12 августа 2012 г. .
^ Geneca (16 марта 2011 г.). "Почему проекты по разработке программного обеспечения терпят неудачу" . Получено 16 марта 2011 г.
^ Махмудул Хак Азад (6 февраля 2011 г.). «Say Hello To Behavior Driven Development» . Получено 12 августа 2012 г.
^ Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых случаев в BPMN для разработки на основе поведения». IEEE Software . 33 (5): 15– 21. doi :10.1109/MS.2016.117. S2CID 14539297.
^ Адам Крейвен (21 сентября 2015 г.). «Основы разработки на основе поведения в масштабе предприятия (BDD)» . Получено 14 января 2016 г.
^ ab Roy Osherove (4 октября 2008 г.). "BDD: Behavior vs. Spec Frameworks" . Получено 12 августа 2012 г.
^ «Что такое три друга в Agile?». Agile Alliance . 2016-06-16 . Получено 2019-06-10 .
^ Кетил Дженсен (13 декабря 2009 г.). "BDD с таблицами сценариев в Fitnesse Slim". Прогулка по прогулке . Wordpress . Получено 12 августа 2012 г.

[BDD_Def_BehaviourDriven-1] "Behaviour-Driven Development". Архивировано из оригинала 1 сентября 2015 года . Получено 12 августа 2012 года .

[IntroBDD-2] Keogh, Liz (2009-09-07). "Введение в развитие, основанное на поведении". SkillsMatterr . Архивировано из оригинала 2021-02-25 . Получено 1 мая 2019 .

[BDD_in_action-3] Джон Фергюсон Смарт (2014). BDD в действии: разработка на основе поведения для всего жизненного цикла программного обеспечения . Manning Publications. ISBN 9781617291654.

[When_to_adopt_BDD-4] Tharayil, Ranjith (15 февраля 2016 г.). «Развитие, основанное на поведении: упрощение пространства сложных проблем». SolutionsIQ . Получено 15 февраля 2018 г.

[BDD_JW-5] Харинг, Рональд (февраль 2011 г.). де Рюитер, Роберт (ред.). «Разработка, основанная на поведении: лучше, чем разработка, основанная на тестировании». Журнал Java (на голландском языке) (1). Журналы Veen: 14–17 . ISSN 1571-6236.

[6] Солис, Карлос; Ван, Сяофэн (2011). «Исследование характеристик разработки, основанной на поведении». 2011 37-я конференция EUROMICRO по программной инженерии и передовым приложениям . С. 383–387 . doi :10.1109/SEAA.2011.76. hdl : 10344/1256 . ISBN 978-1-4577-1027-8. S2CID 3392536.

[BDD_CodeMagazine-7] Bellware, Scott (июнь 2008 г.). «Behavior-Driven Development». Code Magazine . Архивировано из оригинала 12 июля 2012 г. Получено 1 мая 2019 г.

[ATDD_vs_BDD-8] Лиз Кеог (27 июня 2011 г.). «ATDD против BDD и краткая история некоторых связанных с этим вещей» . Получено 6 мая 2019 г.

[9] "Книга RSpec – Вопрос о главе 11: Написание важного программного обеспечения". Архивировано из оригинала 2009-11-07 . Получено 2009-08-09 .

[declarative-10] Мейби, Бен. "Императивные и декларативные сценарии в пользовательских историях". Архивировано из оригинала 3 июня 2010 г. Получено 19 мая 2008 г.

[DDD_Evans-11] Эванс, Эрик (2003). Проектирование на основе предметной области: борьба со сложностью в самом сердце программного обеспечения. Addison-Wesley. ISBN 978-0-321-12521-7. Получено 12 августа 2012 г. .

[BDD_comms-12] Geneca (16 марта 2011 г.). "Почему проекты по разработке программного обеспечения терпят неудачу" . Получено 16 марта 2011 г.

[BDD_CodeProj-13] Махмудул Хак Азад (6 февраля 2011 г.). «Say Hello To Behavior Driven Development» . Получено 12 августа 2012 г.

[ieeeswbdd-14] Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых случаев в BPMN для разработки на основе поведения». IEEE Software . 33 (5): 15– 21. doi :10.1109/MS.2016.117. S2CID 14539297.

[BDD_Enterprise-15] Адам Крейвен (21 сентября 2015 г.). «Основы разработки на основе поведения в масштабе предприятия (BDD)» . Получено 14 января 2016 г.

[BDD_SPEC_OSHEROVE-16] Roy Osherove (4 октября 2008 г.). "BDD: Behavior vs. Spec Frameworks" . Получено 12 августа 2012 г.

[17] «Что такое три друга в Agile?». Agile Alliance . 2016-06-16 . Получено 2019-06-10 .

[FitNesse_BDD-18] Кетил Дженсен (13 декабря 2009 г.). "BDD с таблицами сценариев в Fitnesse Slim". Прогулка по прогулке . Wordpress . Получено 12 августа 2012 г.