В программной инженерии разработка , управляемая поведением ( 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, синтаксис которого аналогичен приведенному выше примеру. Термин « Корнишон» , однако, относится к программным средствам 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 ); рендерер = новый 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 определит, какой метод соответствует какому предложению, с помощью аннотаций и будет вызывать каждый метод по порядку во время выполнения сценария. Текст в каждом пункте в сценарии , как ожидается , в соответствии с текстом шаблона в коде , для этого пункта (например, Учитывая в сценарии , как ожидается, будет сопровождаться пунктом вида «в 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)
- Пример использования
Рекомендации
- ^ a b c d e Север, Дэн (март 2006 г.). «Представляем BDD» . Дэн Норт . Проверено 25 апреля 2019 года .
- ^ а б в «Развитие, управляемое поведением» . Архивировано из оригинала на 1 сентября 2015 года . Проверено 12 августа 2012 года .
- ^ Кио, Лиз (07.09.2009). «Введение в разработку, основанную на поведении» . SkillsMatter . Дата обращения 1 мая 2019 .
- ^ Джон Фергюсон Смарт (2014). BDD в действии: разработка на основе поведения для всего жизненного цикла программного обеспечения . Публикации Мэннинга. ISBN 9781617291654.
- ^ Б с д е е г ч я J K Харинг, Рональд (февраль 2011 г.). де Руйтер, Роберт (ред.). "Разработка, управляемая поведением: Разработка, управляемая тестированием". Журнал Java (на голландском языке). Журналы Veen (1): 14–17. ISSN 1571-6236 .
- ^ Солис, Карлос; Ван, Сяофэн (2011). «Исследование характеристик развития, обусловленного поведением». Программная инженерия и передовые приложения (SEAA), 37-я конференция EUROMICRO, 2011 г. на : 383–387. DOI : 10.1109 / SEAA.2011.76 . hdl : 10344/1256 . ISBN 978-1-4577-1027-8.
- ^ а б в г Bellware, Скотт (июнь 2008 г.). «Развитие, управляемое поведением» . Журнал Code . Архивировано из оригинального 12 июля 2012 года . Дата обращения 1 мая 2019 .
- ^ Тараил, Ранджит (15 февраля 2016 г.). «Поведенческая разработка: упрощение сложной области проблем» . РешенияIQ . Проверено 15 февраля 2018 .
- ^ Лиз Кио (27 июня 2011 г.). «ATDD против BDD, и история некоторых связанных вещей» . Дата обращения 6 мая 2019 .
- ^ «Книга RSpec - вопрос о главе 11: Написание программного обеспечения, которое имеет значение» . Архивировано из оригинала на 2009-11-07 . Проверено 9 августа 2009 .
- ↑ Дэн Норт: Как продать BDD бизнесу. Архивировано 25 ноября 2010 г. на Wayback Machine.
- ^ «Лиз Кио» .
- ^ GOTO 2013 • Интервью с Лиз Кио и Дэном Норт https://www.youtube.com/watch?v=g5WpUJk8He4
- ^ D.North, Представляем RBehave
- ^ S.Miller, InfoQ : RSpec включает RBehave
- ^ а б в г д Норт, Дэн (11 февраля 2007 г.). "Что в рассказе?" . Дэн Норт . Проверено 12 августа 2012 года .
- ^ Маби, Бен. «Императивные и декларативные сценарии в пользовательских историях» . Архивировано из оригинала 3 июня 2010 года . Проверено 19 мая 2008 года .
- ^ «Вкратце - Документация по Салату 0.2.23 (выпуск криптонита)» . салат . Проверено 6 февраля 2020 .
- ^ «Корнишон» . Проверено 7 июня 2020 .
- ^ а б "Что такое JBehave?" . JBehave.org . Проверено 20 октября 2015 года .
- ^ «behavior» - это разработка, управляемая поведением, в стиле Python » . Архивировано из оригинального 22 января 2018 года . Проверено 30 января 2018 года .
- ^ «Возможности написания - документация Behat 3.0.12» . behat документация . Архивировано из оригинального 19 сентября 2015 года . Проверено 20 октября 2015 года .
- ^ а б Эванс, Эрик (2003). Доменно-ориентированный дизайн: преодоление сложности в самой основе программного обеспечения . Эддисон-Уэсли. ISBN 978-0-321-12521-7. Проверено 12 августа 2012 года .
- ^ Норт, Дэн (31 мая 2012 г.). «BDD - это как TDD, если…» . более быстрые организации, более быстрое программное обеспечение . Дэн Норт и партнеры . Проверено 12 августа 2012 года .
- ^ Geneca (16 марта 2011 г.). «Почему программные проекты терпят неудачу» . Проверено 16 марта 2011 года .
- ^ Махмудул Хак Азад (6 февраля 2011 г.). «Передайте привет развитию, основанному на поведении» . Проверено 12 августа 2012 года .
- ^ Любке, Даниэль; ван Лессен, Таммо (2016). «Моделирование тестовых примеров в BPMN для разработки, управляемой поведением». Программное обеспечение IEEE . 33 (5): 15–21. DOI : 10.1109 / MS.2016.117 .
- ^ Адам Крэйвен (21 сентября 2015 г.). "Основы разработки, управляемой поведением предприятия (BDD)" . Проверено 14 января +2016 .
- ^ Кетил Дженсен (13 декабря 2009 г.). «BDD со сценарными таблицами в Fitnesse Slim» . Прогулка пешком . Wordpress . Проверено 12 августа 2012 года .
- ^ "jbehave.org/team-list" . JBehave. 2017-05-28 . Дата обращения 1 мая 2019 .
- ^ а б Рой Ошеров (4 октября 2008 г.). «BDD: поведение и спецификации» . Проверено 12 августа 2012 года .
- ^ Джейсон Сейфер (7 декабря 2011 г.). «Введение в RSpec» . Проверено 27 октября 2012 года .
- ^ "Что такое три амигранта в Agile?" . Agile Alliance . 2016-06-16 . Проверено 10 июня 2019 .