Используете ли вы BDD по назначению?

Насколько я просек тему, то парадоксальным образом BDD не связан ни с тестированием ни с разработкой. BDD - это вопрос менеджмента, и тут он вполне себе плавно пересекается с Agile. Основная задача BDD - чтобы вся команда, а также клиент, разговаривали на одном языке. И этим формальным языком является Gherkin - его могут прочесть как технический персонал, так и нетехнический, и в том числе дописывать и вносить коррективы в спецификации. Автотесты - это лишь небольшой бонус, но далеко не первичная фича BDD.

Сам я не работал в BDD-команде, и в свое время был ярым противником BDD/Gherkin, то сейчас мне кажется, что BDD весьма эффективен для менеджмента. Главное, что вся команда должна следовать BDD, а не всего лишь тестировщик-автоматизатор.

А приставка BDD по отношению к тем или иным тулзам - не более чем маркетинговая уловка.

3 лайка

Сам я не работал в BDD-команде

Ясно понятно.

По теме скажешь чего-нибудь?

Отчего же не сказать, скажу.
Работал с BDD и находил его весьма полезным для проектирования тестов на продуктовой разработке.
Это когда есть продукт, который кастомизируется под каждого пользователя/компанию.
Здесь всё было просто. Есть общий пулл регрессионных тестов и набор тестов под фичу.
Когда у программиста есть спека и набор тестов, есть неиллюзорная вероятность, что он реализует фичу с первого раза. Это профит. Из минусов - тесты пытается писать “каждая кухарка”. Особенно, если руководство, которое считает, что Гиркин - это, позвольте процитировать

Основная задача BDD - чтобы вся команда, а также клиент, разговаривали на одном языке. И этим формальным языком является Gherkin - его могут прочесть как технический персонал, так и нетехнический, и в том числе дописывать и вносить коррективы в спецификации.

Таким образом, когда я вижу как человек вкладывает скрытые смыслы во что-то, с чем не работал - это вызывает только улыбку и нежелание что-то доказывать.

1 лайк

Спасибо за высказанное мнение

Ну так в этом и фишка этого геркина - писать тесты человеческим (не алгоритмическим) языком, как раз для того, чтобы “каждая кухарка” его писала. И проблема не в том, что менеджмент неправильно понимает суть BDD, ту самую которую ты процитировал (хотя менеджмент эту суть как раз тоже не понимает), а в том, что менеджмент неправильно понимает как и для чего этот BDD использовать. Услышали модное слово и решили: “крутяк! Теперь аналитики будут писать автотесты! Проблема с регрессом решена!”

Здесь не нужен геркин, это можно и на C# написать. И проблема, из-за которой я завел тему именно в том, что на том же C# (или другом нормальном ЯП) автотесты писать гораздо проще и эффективнее, когда не приходится бороться с глючными и убогими BDD-фреймворками. Факт в том, что применение BDD-фреймворка для автотестов в большинстве случаев не оправдано и не достигает той светлой цели, когда “исполняемая документация” пишется аналитиками и продукт-овнерами

1 лайк

Поэтому вопрос такой: стоит ли оно того? Кто-то это использует в том виде, в котором gherkin действительно приносит пользу, а не вред?

Мнение: не стоит. Видел неправильные применения, видел вред, не видел пользы.

Обоснование: Gherkin это подход, который позволяет в общих фразах описать “а что это должно делать”. Никакой полезной функции это не несёт, это декорация высокого уровня, избыточная нагрузка, а не рабочий инструмент. С тем же успехом можно Gherkin-описание прикреплять комментарием: что так что так вы получаете описание, а с реализацией Gherkin не связан никак и на внутреннюю структуру реализации не отображается, “Мы вам сказали что оно делает, но если вы заглянете в код или даже keywords, вы не поймёте как это сделано если вы не разбираетесь хотя бы в алгоритмах”.

Создавал по вопросу отдельную тему:

Также рекомендую презентацию “О вреде огурцов”:

И другие из темы “Вся правда об автоматизации тестирования”:

5 лайков

Здесь не нужен геркин, это можно и на C# написать. И проблема, из-за которой я завел тему именно в том, что на том же C# (или другом нормальном ЯП) автотесты писать гораздо проще и эффективнее, когда не приходится бороться с глючными и убогими BDD-фреймворками. Факт в том, что применение BDD-фреймворка для автотестов в большинстве случаев не оправдано и не достигает той светлой цели, когда “исполняемая документация” пишется аналитиками и продукт-овнерами

Ну, как бы всё правильно. Но если у нас больше чем один автотестер пишет, то поддерживать стандарт становится трудно. Грубо говоря, польза бддшных тестов состоит в том, что когда и кто бы ни открыл любой фича файл, он увидит так абсолютно стандартный код. От любого из “написателей”.
Просто хотя бы потому, что по-другому написать нельзя.

2 лайка

когда-то выбрали 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"));
}
2 лайка

Какие причины? Расскажи пожалуйста?

Из того опыта, что я приобрел в результате использования BDD-фреймворка (specflow), могу выделить следующие плюсы и минусы.

Плюсы

  • тесты наглядные
  • тесты пишутся очень быстро (при наличии готовых шагов)

Минусы

  • из-за требования к универсальности и переиспользованию шагов, их написание - это основная головная боль
    – передача контекста между шагами (страница, DTO-шка) делается через глобальную мапу (ключ-значение). При этом, если шаг универсальный и может следовать за разными шагами (в одном тесте после одного шага, в друом - после другого), которые передают разные контексты, то в шаге приходится костылять для определения контекста. Изящной такую архитектуру не назовешь

В этом месте, на стыке между шагами, я вижу основную сложность, основной челенж, который приходится преодолевать. И на мой взгляд сложность эта неестественная, и вызвана тем, что по идее фреймворка шаги должны быть независимыми, а в тестах между ними возникает зависимость. Я честно говоря не нашел красивого решения этого противоречия

  • плюс ко всему BDD-фреймворки имеют ограниченный функционал, я сталкивался с нехваткой группировки тестов, могут быть и другие ограничения, потому что в отличие от unit-фреймворков, эти ещё молодые и зеленые

Писал в BDD стиле на Robot Framework. По сравнению с “чистыми” BDD-фреймворками RF гораздо гибче (объекты передаются на ура). Остались только положительные впечатления и привычка писать в таком стиле. Вот как теперь пишу на java :slight_smile:
Разработчики тоже стали перенимать этот стиль. Теперь у нас и юниты выглядят также.
К “чистым” фреймворкам пытался приглядываться пару раз, но отпугнули их ограничения.

1 лайк

А как это у Вас получается? Можете примерно описать, что за продукт и как достигается “стандартный код”, дать примеры такого кода?

Потому что в моей практике я видел как при попытке стандартизировать продукт, который кастомизируется под каждого пользователя, всё это превратилось в грандиозный fail, и от стандартизации описаний контролов отказались, перейдя к свободным идентификаторам. Уж слишком кастомизируемым оказался продукт, превратив создание стандартных описаний в неподъёмную задачу.

Вкратце опишу систему:

  • Портал, скажем, Liferay, регистрация пользователя (у которой могут
    быть разные поля, кастомизируемые под каждого заказчика)
  • Под портал есть много модулей — профиль пользователя, лента на базе
    RSS feeds, баннеры, произвольный HTML контент…
  • У портала есть интенационализация в которой порядка 10,000 ключей
    только в базовой поставке (см. тот же Liferay), а есть же ещё и модули (то есть если вы
    автоматизируете манипуляции с ключами интенационализации Портала это
    заведомо не все поймут в коде).
  • К порталу подключаются игрушки, а они все разные — допустим,
    блэкджек, рулетка, покер, “однорукие бандиты”, лото, виртуальные
    скачки…

Первый раз вижу не-PageObject реализацию фреймворка :slight_smile: Выглядит симпатично. А как будет реализовываться user.clicks на элементы произвольной страницы?

Примерно так

public void clicks(Selement element) {
    element.self().click();
}

Есть где-нибудь более полная реализация фреймворка и примеров тестов в общем доступе? Интересно посмотреть

К сожалению, в общем доступе ничего нет :frowning:

Я как раз эту тему поднимал в своём докладе на последнем SeleniumCamp:

“Bullshit driven development”
http://seleniumcamp.com/materials/bullshit-driven-development/

Если вкратце - идея BDD красивая . Я бы хотел жить в мире, где это работает. Но оно не работает. BDD фреймворки добавляют много геморроя, но не дают никаких преимуществ, увы. Их выбирают из-за отчётов.

Изначальная цель BDD - это вовсе не отчёты, а написание спеков ВМЕСТЕ С БИЗНЕСОМ, и этого нигде не происходит. Как тут правильно заметили, того же результата гораздо проще добиться обычным кодом на обычном языке программирования.

9 лайков

Да, мне понравилось, как в роботе исторически появился BDD. На вопрос “а где у вас модный BDD”, разработчики простым коммитом добавили поддержку ключевых слов, но не стали “впаривать” это, как святой грааль. В итоге в тестах нет жестких ограничений, тестировщик сам выстраивает нужную ему лаконичность и стиль, не привязывается к “красивым” отчетам (они и так приемлемые).

Как пример, сейчас у нас на тестах, связанных с devops, их логика строится в идеологии BDD, но мы нигде об этом не говорим, не разработчикам, не менеджерам.

1 лайк
  1. Андрей основную причину хорошо описал. И у нас бизнес не пишет сценарии.
  2. Тратим время на создание лишнего кода (мапинг степов jBehave & Java). Зачастую в шаге просто инициализация объекта страницы + вызов одного метода, например клик по элементу.
  3. Передача контента между шагами.

Очень хороший пример от Паши:

к чему-то такому буду и я стремиться, только буду 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 тесты :relaxed:
Я простенький POC написал, как бы я реализовал это, Кстати, буду рад за конструктивные замечания.

А как это у Вас получается? Можете примерно описать, что за продукт и как достигается “стандартный код”, дать примеры такого кода?

Эммм… Вы знакомы со структурой Gherkin? Ну, то есть как в feature файле описывается тест?
Если да, то я удивляюсь откуда возникает этот вопрос.