В рунете есть множество статей, касающихся применения BDD-методологии, а также я встречал проекты и общался с людьми, которые используют BDD и Cucumber, и иногда примеры использования являются весьма экзотическими. Одна из команд продвигала данный подход, аргументируя это тем, что с помощью Gherkin-спецификаций они плавно подводят ручных тестировщиков к автоматизации.😀Встречались команды, которые изо всех сил старались рефакторить многолетний legacy и переписать AT без «огурца», ну а кто-то просто так привык. Но меня не покидает мысль, что когда-то лет 15 назад все прочитали одну и ту же плохо переведённую статью на эту тему и до сих пор многие считают, что очень здорово писать тестовые сценарии на Gherkiin.

Попытаемся разобраться. Основоположник BDD Дэн Норт выступал за продвижение бизнес-языка для описания сценариев, который разработчики напрямую применяют в коде. По его мнению, нужен был язык, являющийся связующим звеном между заказчиком и исполнителем. Из концепции BDD user story — это некий эквивалент функциональных требований, представленных в виде бизнес-сценария. И тут мы переходим к фреймворку Cucumber. Согласно документации, user story — это единица планирования, а её acceptance criteria записываются на Gherkin. При этом Gherkin-сценарии пишутся не одним человеком, а создаются в результате коллаборации всей команды — бизнес-специалистов и технических специалистов. Аслак Хеллесёй, автор фреймворка, подчёркивает, что Cucumber — это в первую очередь инструмент сотрудничества, а не инструмент тестирования.

Что мы видим чаще всего на практике и что противоречит основополагающим тезисам BDD: ❗user story вместе с acceptance criteria на Gherkin выполняет функцию тест-кейсов и часто дублирует кейсы из TMS; ❗user story не выполняет концептуальную функцию одного из видов функциональных требований; ❗Gherkin-сценарии в одиночку пишут автотестеры, потому что больше никто не лезет в код АТ и не знает, как они устроены; ❗ user story вместе с Gherkin-сценариями часто позиционируется как разновидность тестовой документации, и по ней обычно не работает ни разработчик, ни аналитик, ни тем более бизнес; ❗ user story даже при концептуальном подходе не самодостаточна и не содержит многих важных артефактов, какие содержат классически описанные функциональные требования, — например, схем функционального взаимодействия, sequence-диаграмм, таблиц маппинга и многого другого; ❗ Gherkin-сценарии замедляют написание и рефакторинг автотестов.

Подведем итог. Из вышесказанного я сделал вывод, что Cucumber вполне может быть эффективен в команде fullstack-специалистов, обладающих сопоставимыми скиллами, от аналитика и архитектора, которые описывают эти user story, до тестировщика и разработчика, которые по ним работают дальше по цепочке. На практике такой состав команд можно встретить редко. Уверен, есть команды, в которых этот инструмент и в общем BDD-подход прошли изолированную эволюцию и применяются по-своему, со своим осязаемым профитом. Делитесь в комментариях вашим опытом, очень интересно услышать вашу точку зрения👍