Насколько я просек тему, то парадоксальным образом BDD не связан ни с тестированием ни с разработкой. BDD - это вопрос менеджмента, и тут он вполне себе плавно пересекается с Agile. Основная задача BDD - чтобы вся команда, а также клиент, разговаривали на одном языке. И этим формальным языком является Gherkin - его могут прочесть как технический персонал, так и нетехнический, и в том числе дописывать и вносить коррективы в спецификации. Автотесты - это лишь небольшой бонус, но далеко не первичная фича BDD.
Сам я не работал в BDD-команде, и в свое время был ярым противником BDD/Gherkin, то сейчас мне кажется, что BDD весьма эффективен для менеджмента. Главное, что вся команда должна следовать BDD, а не всего лишь тестировщик-автоматизатор.
А приставка BDD по отношению к тем или иным тулзам - не более чем маркетинговая уловка.
Отчего же не сказать, скажу.
Работал с BDD и находил его весьма полезным для проектирования тестов на продуктовой разработке.
Это когда есть продукт, который кастомизируется под каждого пользователя/компанию.
Здесь всё было просто. Есть общий пулл регрессионных тестов и набор тестов под фичу.
Когда у программиста есть спека и набор тестов, есть неиллюзорная вероятность, что он реализует фичу с первого раза. Это профит. Из минусов - тесты пытается писать “каждая кухарка”. Особенно, если руководство, которое считает, что Гиркин - это, позвольте процитировать
Основная задача BDD - чтобы вся команда, а также клиент, разговаривали на одном языке. И этим формальным языком является Gherkin - его могут прочесть как технический персонал, так и нетехнический, и в том числе дописывать и вносить коррективы в спецификации.
Таким образом, когда я вижу как человек вкладывает скрытые смыслы во что-то, с чем не работал - это вызывает только улыбку и нежелание что-то доказывать.
Ну так в этом и фишка этого геркина - писать тесты человеческим (не алгоритмическим) языком, как раз для того, чтобы “каждая кухарка” его писала. И проблема не в том, что менеджмент неправильно понимает суть BDD, ту самую которую ты процитировал (хотя менеджмент эту суть как раз тоже не понимает), а в том, что менеджмент неправильно понимает как и для чего этот BDD использовать. Услышали модное слово и решили: “крутяк! Теперь аналитики будут писать автотесты! Проблема с регрессом решена!”
Здесь не нужен геркин, это можно и на C# написать. И проблема, из-за которой я завел тему именно в том, что на том же C# (или другом нормальном ЯП) автотесты писать гораздо проще и эффективнее, когда не приходится бороться с глючными и убогими BDD-фреймворками. Факт в том, что применение BDD-фреймворка для автотестов в большинстве случаев не оправдано и не достигает той светлой цели, когда “исполняемая документация” пишется аналитиками и продукт-овнерами
Поэтому вопрос такой: стоит ли оно того? Кто-то это использует в том виде, в котором gherkin действительно приносит пользу, а не вред?
Мнение: не стоит. Видел неправильные применения, видел вред, не видел пользы.
Обоснование: Gherkin это подход, который позволяет в общих фразах описать “а что это должно делать”. Никакой полезной функции это не несёт, это декорация высокого уровня, избыточная нагрузка, а не рабочий инструмент. С тем же успехом можно Gherkin-описание прикреплять комментарием: что так что так вы получаете описание, а с реализацией Gherkin не связан никак и на внутреннюю структуру реализации не отображается, “Мы вам сказали что оно делает, но если вы заглянете в код или даже keywords, вы не поймёте как это сделано если вы не разбираетесь хотя бы в алгоритмах”.
Создавал по вопросу отдельную тему:
Также рекомендую презентацию “О вреде огурцов”:
И другие из темы “Вся правда об автоматизации тестирования”:
Здесь не нужен геркин, это можно и на C# написать. И проблема, из-за которой я завел тему именно в том, что на том же C# (или другом нормальном ЯП) автотесты писать гораздо проще и эффективнее, когда не приходится бороться с глючными и убогими BDD-фреймворками. Факт в том, что применение BDD-фреймворка для автотестов в большинстве случаев не оправдано и не достигает той светлой цели, когда “исполняемая документация” пишется аналитиками и продукт-овнерами
Ну, как бы всё правильно. Но если у нас больше чем один автотестер пишет, то поддерживать стандарт становится трудно. Грубо говоря, польза бддшных тестов состоит в том, что когда и кто бы ни открыл любой фича файл, он увидит так абсолютно стандартный код. От любого из “написателей”.
Просто хотя бы потому, что по-другому написать нельзя.
сценарии понятны клиенту, бизнес-аналитику, новичку. Они же могут
писать их;
наглядно на каком шаге упал тест.
Сейчас сценариями занимаются только тестировщики. Думаю в моем случае лучше будет уйти от BDD. Будем писать тесты c хорошим описанием в стиле:
@Test
@Description("The first link should be 'automated-testing.info'")
public void googleSearchTest() {
GooglePage page = open("http://google.com", GooglePage.class);
SearchResultsPage results = page.searchFor("automated-testing.info");
results.getResults().get(0).shouldHave(text("automated-testing.info"));
}
Из того опыта, что я приобрел в результате использования BDD-фреймворка (specflow), могу выделить следующие плюсы и минусы.
Плюсы
тесты наглядные
тесты пишутся очень быстро (при наличии готовых шагов)
Минусы
из-за требования к универсальности и переиспользованию шагов, их написание - это основная головная боль
– передача контекста между шагами (страница, DTO-шка) делается через глобальную мапу (ключ-значение). При этом, если шаг универсальный и может следовать за разными шагами (в одном тесте после одного шага, в друом - после другого), которые передают разные контексты, то в шаге приходится костылять для определения контекста. Изящной такую архитектуру не назовешь
В этом месте, на стыке между шагами, я вижу основную сложность, основной челенж, который приходится преодолевать. И на мой взгляд сложность эта неестественная, и вызвана тем, что по идее фреймворка шаги должны быть независимыми, а в тестах между ними возникает зависимость. Я честно говоря не нашел красивого решения этого противоречия
плюс ко всему BDD-фреймворки имеют ограниченный функционал, я сталкивался с нехваткой группировки тестов, могут быть и другие ограничения, потому что в отличие от unit-фреймворков, эти ещё молодые и зеленые
Писал в BDD стиле на Robot Framework. По сравнению с “чистыми” BDD-фреймворками RF гораздо гибче (объекты передаются на ура). Остались только положительные впечатления и привычка писать в таком стиле. Вот как теперь пишу на java
Разработчики тоже стали перенимать этот стиль. Теперь у нас и юниты выглядят также.
К “чистым” фреймворкам пытался приглядываться пару раз, но отпугнули их ограничения.
А как это у Вас получается? Можете примерно описать, что за продукт и как достигается “стандартный код”, дать примеры такого кода?
Потому что в моей практике я видел как при попытке стандартизировать продукт, который кастомизируется под каждого пользователя, всё это превратилось в грандиозный fail, и от стандартизации описаний контролов отказались, перейдя к свободным идентификаторам. Уж слишком кастомизируемым оказался продукт, превратив создание стандартных описаний в неподъёмную задачу.
Вкратце опишу систему:
Портал, скажем, Liferay, регистрация пользователя (у которой могут
быть разные поля, кастомизируемые под каждого заказчика)
Под портал есть много модулей — профиль пользователя, лента на базе
RSS feeds, баннеры, произвольный HTML контент…
У портала есть интенационализация в которой порядка 10,000 ключей
только в базовой поставке (см. тот же Liferay), а есть же ещё и модули (то есть если вы
автоматизируете манипуляции с ключами интенационализации Портала это
заведомо не все поймут в коде).
К порталу подключаются игрушки, а они все разные — допустим,
блэкджек, рулетка, покер, “однорукие бандиты”, лото, виртуальные
скачки…
Если вкратце - идея BDD красивая . Я бы хотел жить в мире, где это работает. Но оно не работает. BDD фреймворки добавляют много геморроя, но не дают никаких преимуществ, увы. Их выбирают из-за отчётов.
Изначальная цель BDD - это вовсе не отчёты, а написание спеков ВМЕСТЕ С БИЗНЕСОМ, и этого нигде не происходит. Как тут правильно заметили, того же результата гораздо проще добиться обычным кодом на обычном языке программирования.
Да, мне понравилось, как в роботе исторически появился BDD. На вопрос “а где у вас модный BDD”, разработчики простым коммитом добавили поддержку ключевых слов, но не стали “впаривать” это, как святой грааль. В итоге в тестах нет жестких ограничений, тестировщик сам выстраивает нужную ему лаконичность и стиль, не привязывается к “красивым” отчетам (они и так приемлемые).
Как пример, сейчас у нас на тестах, связанных с devops, их логика строится в идеологии BDD, но мы нигде об этом не говорим, не разработчикам, не менеджерам.
Андрей основную причину хорошо описал. И у нас бизнес не пишет сценарии.
Тратим время на создание лишнего кода (мапинг степов jBehave & Java). Зачастую в шаге просто инициализация объекта страницы + вызов одного метода, например клик по элементу.
Передача контента между шагами.
Очень хороший пример от Паши:
к чему-то такому буду и я стремиться, только буду PageObject подход использовать. Думаю будет выглядеть как-то так:
@Test
public void userCanSearch() {
GooglePage page = open("http://google.com", GooglePage.class);
page.searchFor("Selenide: concise UI tests in Java")
.getResults().get(0)
.shouldHave(text("Selenide: concise UI tests in Java"));
}
Такой тест написать быстрее чем создавать дополнительные классы с мапингом. Может даже девелоперы будут писать UI тесты
Я простенький POC написал, как бы я реализовал это, Кстати, буду рад за конструктивные замечания.
testomat.io управление авто тестами
Выглядит симпатично. А как будет реализовываться user.clicks на элементы произвольной страницы?
