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

bdd
Теги: #<Tag:0x00007fedb955cc70>

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

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

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

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

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

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


Внедрение автоматизации для Web в команду
Выбор окружения для автоматизации тестирование web-приложения
Выбор инструмента для автоматизации или стоит ли использовать BDD?
Каковы преимущества и недостатки BDD подхода написания тестов?
(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: