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

step-object
design-patterns
bdd
gherkin
framework
Теги: #<Tag:0x00007f7b68ed80d8> #<Tag:0x00007f7b6470a648> #<Tag:0x00007f7b6470ed60> #<Tag:0x00007f7b64715908> #<Tag:0x00007f7b65979040>

(Александр Таранков) #1

Кто-то использует BDD по его первоначальному назначению - написание спецификации, которая будет автоматически запускаться для проверки работоспособности функционала? Причем написание спецификации, естественно, происходит ДО начала разработки и может в таком виде использоваться для автоматической проверки?

Проблема в том, что использование BDD-фреймворков (behave, specflow и т.д.), в основе которых лежит язык описания сценариев gherkin, сильно затрудняет написание автотестов.

Сложность складывается из двух составляющих:

  1. Использование дополнительного инструмента неизбежно ведет к борьбе с его багами и фичами
  2. Парадигма gherkin-а подразумевает, что шаги (Steps) - это независимые функции, следовательно, для их использования в одном сценарии, где между шагами надо передавать состояние и данные, приходится делать множество дополнительных приседаний

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


Выбор инструмента для автоматизации или стоит ли использовать BDD?
Каковы преимущества и недостатки BDD подхода написания тестов?
Выбор окружения для автоматизации тестирование web-приложения
Внедрение автоматизации для Web в команду
Используете ли вы BDD по назначению? [v2]
(olegS) #2

использую specflow уже месяца три и то по причине того что он умеет делать репорты, кода конечно приходится больше городить, думаю тут по ситуации нужно смотреть …


(Дмитрий Жарий) #3

Сам подход BDD по созданию тестов:

  • Спецификация через пример
  • Думать в первую очередь о том, что должен код делать, а не то как тестировать то, что уже написано
  • Использовать Arrange Act Assert или Given When Then (без ограничений Gherkin) внутри кода тестов для логического разделения
  • Использовать Fluent-assert’ы со всякими там Should.BeGreaterThan(42)

– это реально эффективный и классный подход

Запускаемая спецификация же, для меня, а точнее ее конкретные реализации по типу Cucumber или Specflow или другие – это излишки, которые отнимают время на поддержку, усложняют код, либо заставляют копи-пастить.
Результаты не стоят затраченного времени. За время, потраченное на написание на то, чтобы правильно передать параметры из Step в Step, можно написать свою библиотеку для создания красивых отчетов.

Ничего не имею против BDD-тулов, но нынешние реализации считаю очень ограниченными. Gherkin, в контексте конкретных реализаций, считаю очень ограничивающим языком.


(Александр Таранков) #4

У меня сложилось аналогичное мнение: что BDD - это больше о правильном подходе к автоматизации тестирования и обеспечению качества вообще.

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

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

То есть это к вопросу о том, “что же мы автоматизируем?”. Нельзя автоматизировать то, чего нет. Надо сначала организовать процесс, потом его автоматизировать, а не наоборот. Всё ИМХО.

Но хотелось бы услышать и истории успеха. Может быть кто-то может рассказать об успешном опыте применения Serenity (Thycidides) - какую пользу вы получаете от его использования, какие проблемы приходится решать при его использовании?

P.S. насчет выбора фреймворка по критерию “он умеет строить отчеты”, моё мнение такое: отчеты должен хорошо уметь строить CI-tool или даже TestManagement tool. Использовать для тестирования только фреймворк автоматизации для меня кажется дикостью. Потому что надо ж как-то ещё и ручное тестирование проводить. Поэтому я склоняюсь к тому, что должен быть Test Management Tool, где храняться как сценарии, так и отчеты о тестировании, а фреймворк автоматизации должен уметь с ним интегрироваться


(Michael Bodnarchuk) #5

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

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

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


(Andrey Myasnikov) #6

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

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


(Александр Таранков) #7

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


(Andrey Myasnikov) #8

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

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

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


(Александр Таранков) #9

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

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

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


(rpwheeler) #10

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

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

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

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

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

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


(Andrey Myasnikov) #11

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

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


(Serhii Tanchenko) #12

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

(Александр Таранков) #13

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


(Александр Таранков) #14

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

Плюсы

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

Минусы

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

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

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

(Павел Ветохин) #15

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


(rpwheeler) #16

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

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

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

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

(Александр Таранков) #17

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


(Павел Ветохин) #18

Примерно так

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

(Александр Таранков) #19

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


(Павел Ветохин) #20

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