Behavior-Driven Development отживает свое? Почему все отказываются от Cucumber⁠⁠

Когда-то Behavior-Driven Development задумывался как классная штука. Предполагалось, что с его помощью бизнес будет описывать, как должен работать продукт, тестировщики — добавлять корнер-кейсы («а что будет, если сделать шаг влево или вправо?»), а разработчики — писать код автотестов и делать продукты, которые эти тесты проходят.

Главный инструмент BDD — Cucumber — позволил автоматизировать тесты, описывая их на языке Gherkin и связывая эти описания с исполняемым кодом. В итоге должен был получаться результат, который устраивает и бизнес, и QA.

Но что-то пошло не так. Сегодня в адрес Cucumber все чаще можно услышать критику. Его создатель Аслак Хэллисей признал, что: «Большинство используют Cucumber не для BDD, а просто как инструмент тестирования. Если так, то он ничем не лучше других фреймворков».

Кто в этом виноват и что делать? Попробуем разобраться.

Behavior-Driven Development отживает свое? Почему все отказываются от Cucumber Cucumber, QA, Длиннопост

Что пошло не так

В идеальном Behavior-Driven Development-мире бизнес берет латте, садится рядом с тобой и вы долго и счастливо пишете сценарии вместе. В реальности же он тебя просто отшивает: «У нас нет времени разбираться в этих Given-When-Then. Главное, чтобы работало. А как — это ваши проблемы». В итоге вся фишка BDD — описание требований на общем языке — теряется.

Разработчики тоже не в восторге: Gherkin для них — это лишняя абстракция, которая только мешает. Каждый шаг в Gherkin требует реализации в коде. Вместо упрощения получается дополнительный слой — step definitions нужно писать, поддерживать и постоянно рефакторить. В итоге мы имеем 10 сценариев → 100 шагов → 500 строк кода, где 80% — это повторяющиеся вызовы.

Если команда тупо перекладывает готовые тест-кейсы в Gherkin, это лишняя работа, которая не имеет смысла.

Почему Cucumber не так хорош

Он тормозит. Высокоуровневые сценарии, особенно в UI-тестах, превращают CI/CD в ад. Каждый прогон ты сидишь и ждешь, когда же он доползет до конца.

Это темный лес. В реальных проектах сценарии не более информативны, чем код на незнакомом ЯП.

Это больно. Любое изменение в логике — и приходится переписывать шаги, а потом чинить тесты. А если у тебя несколько команд работают с одними и теми же сценариями — жди конфликтов.

Он хрупкий и жестко завязан на структуру. Нужно привыкать к нему и следить за реализацией «названий» шагов, чтобы правильно вызывать их в feature-файлах. Одно неосторожное движение — и все, тесты посыпались как карточный домик. Перефразировали текст в требованиях? Надо бегом править все фичи. Изменили селектор на фронте? Готовимся к падениям.

Он все усложняет. Он приносит еще один уровень абстракции, с которым нужно считаться при дебаге.

VLM все меняет

Можно ли сохранить удобство написания тест-кейсов в свободной форме, но при этом избавиться от жестких синтаксических правил? Похоже, что да. И ключом к этому решению должны стать vision-language модели (VLM) — мультимодальные нейросети, которые могут одновременно обрабатывать изображения и текстовые описания. Они принимают на вход скриншот интерфейса и описание не в жестко структурированной нотации и подготовленных фразах, а в естественных формулировках, понимают контекст и определяют, какой именно элемент соответствует этой инструкции.

Недавно команда BugBuster внедрила этот подход, запустив ИИ-систему для управления тестированием.

Вот как это работает:

Описываешь действия за 5 минут. Просто пишешь тест-кейс на человеческом языке.

Запускаешь тест в один клик. Больше не нужно каждый день править селекторы из-за того, что фронтендер решил рефакторнуть верстку.

Получаешь результат через минуту. Пока ты идешь за кофе, система сама проверяет, что в корзину все добавилось, кнопки нажались, а формы отправились.

Хочешь попробовать? Бесплатный тест-драйв тут.

Источники

Cucumber QA Длиннопост