BDD подход - новый взгляд на известные практики
В последние годы BDD (Behaviour Driven Development — «Разработка через поведение») приобретает все большую популярность. Благодаря развитию DevOps технологий и вниманию к CI/CD процессу интерес к BDD неуклонно нарастает. В то же время многие считают BDD всего лишь нотацией, используемой при автоматизации тестирования, и нередко даже матерые тестировщики не видят разницы между BDD и TDD (Test Driven Development — "Разработка через тестирование") методологиями. А ведь ни в названии, ни в определении BDD тестирование не упоминается.
В википедии BDD определяется как процесс. Процесс, который призван содействовать улучшению сотрудничества заинтересованных лиц, участвующих в создании программного обеспечения как с технической, так и нетехнической стороны. Цель этого процесса - выработать единое понимание поведения приложения. Именно эта формулировка отражена в названии и определяет основное предназначение подхода.
Согласно такой дефиниции BDD имеет такое же отношение к тестированию как и другим фазам разработки.
Исторически BDD действительно является продолжением TDD методологии, предлагая основывать разработку на сценариях приемочного тестирования. Однако, не менее важная его составляющая - привнесенная из DDD (Domain Driven Design — Предметно-ориентированное проектирование) концепция DSL ( Domain-Specific Language - специфичный предметно-ориентированный язык) - естественного языка, понятного всем участникам процесса и позволяющего объединить постановку задачи, тесты и документацию воедино.
Основоположники подхода не раз подчеркивали, что рассматривают BDD, в первую очередь, как средство улучшение коммуникаций между командой разработки и бизнесом. Дэн Норт (Dan North) говорил о BDD как о расширении практик TDD от использования внутри среды разработчиков до применения в качестве единого языка общения всех стейкхолдеров проекта и делал акцент на расшифровке последнего D как development: end-to-end software development.
Собственно в этой глобализации видятся перспективы этой методологии, и одновременно кроется ее основная проблема. Применение BDD не ограничивается использованием новых технологических средств, но влечет изменения подходов, образа мышления и даже корпоративной культуры. Оно может быть успешным только при условии вовлеченности всех заинтересованных лиц. Внедрение BDD бросает вызов всем причастным к разработке и, в частности, аналитикам. Именно от аналитика ожидается весомый вклад в создание языка описания функциональности, понятного каждому участнику. Ведь именно аналитик является связующим звеном между бизнесом и разработкой. При этом фокус его деятельности смещается от передачи информации в сторону налаживания взаимодействия. Согласно емкому образу, который использовали Dan North и Martin Fowler, аналитик выступает скорее в роли строителя мостов, а не лодочника.
По достоинству оценив открывающиеся возможности нового подхода, аналитики стали адаптировать свои рабочие инструменты. В арсенале методов сбора требований давно существует техника определения Acceptance Criteria (критериев приемки) как условий, которые должны быть выполнены. чтобы проект считался завершенным. Наличие четко определенного списка таких условий позволяет сформировать ожидания клиентов на этапе выявления требований, а проверка их в ходе тестирования убедиться в соответствии программного обеспечения этим ожиданиям. Эта практика, позволяющая связать требования и тестовые сценарии легла в основу реализации BDD.
Еще одной техникой, неразрывно связанной с BDD, является Specification by Example (Спецификация на основе примеров, SbE). Она имеет и другие названиями, подчеркивающие влияние результатов, полученных с ее помощью, на все стадии процесса разработки: example-driven development, Agile Acceptance Testing, Test-Driven Requirements. Собственно ничего принципиально нового в приведении примеров в качестве иллюстраций логики работы системы нет. Однако, благодаря публикациям Гойко Аджича (Gojko Adzic), формализовавшего подход, методика стала мощным средством общения в проекте. Суть ее сводится к использованию примеров в ходе обсуждения требований как с бизнесом, так и с командой с последующим внесением их в документацию. Разработанные в ходе сбора требований примеры служат единым источником информации и применяются в последующих фазах: становятся техническим заданием для реализации, ложатся в основу тестовых сценариев, демонстрируют разработанную функциональность пользователям на этапе внедрения. Формат описания примеров рекомендует выделять входящие параметры и результаты работы приложения, а также сопровождать примеры описанием контекста - выполняемых шагов процесса. Таким образом, примеры фактически представляют собой исполняемую спецификацию, т.е. набор сценариев, пригодных для ручного тестирования и легко поддающихся автоматизации.
Изначально рекомендаций относительно используемых нотаций техники Specification by Example и Acceptance Criteriaне не содержали. Acceptance Criteria описывались в свободном формате. Specification by Example, как правило, представляли собой таблицы с комментариями. Однако, по прошествии 10 лет развития подхода можно сказать, что с большим отрывом лидирует Given-When-Then, или так называемая,Gherkin нотация.
Gherkin – это структурированный естественный язык, который используется для описания сценариев поведения системы. Его популярность можно объяснить тем, что Gherkin выдерживает точный баланс между формализацией и свободой изложения. Повторяемость структур облегчает понимание сценариев и их автоматизацию разработчиками. В то же время благодаря близости к естественному языку этот формат легко воспринимается и представителями бизнеса, не требует специальной подготовки.
Безусловно на распространение этой нотации повлияло и ее использование фреймворками автоматизированного тестирования. Разработанная первоначально в рамках Jbehave , она сейчас поддерживается всеми популярными приложениями этого класса, включая такие как Cucumber и SpecFlow. Язык Gherkin расширяет шаблон Given-When-Then дополнительными ключевыми словами и делает его полноценным средством описания сценариев, сохраняя при этом краткость. Многие приложения, например Cucumber, позволяют включать в описание таблицы, что дает возможность сделать сценарии бол