Кто-то использует BDD по его первоначальному назначению - написание спецификации, которая будет автоматически запускаться для проверки работоспособности функционала? Причем написание спецификации, естественно, происходит ДО начала разработки и может в таком виде использоваться для автоматической проверки?
Проблема в том, что использование BDD-фреймворков (behave, specflow и т.д.), в основе которых лежит язык описания сценариев gherkin, сильно затрудняет написание автотестов.
Сложность складывается из двух составляющих:
Использование дополнительного инструмента неизбежно ведет к борьбе с его багами и фичами
Парадигма gherkin-а подразумевает, что шаги (Steps) - это независимые функции, следовательно, для их использования в одном сценарии, где между шагами надо передавать состояние и данные, приходится делать множество дополнительных приседаний
Поэтому вопрос такой: стоит ли оно того? Кто-то это использует в том виде, в котором gherkin действительно приносит пользу, а не вред? Или достиг уровня просветления, на котором он знает как получить из этого пользы больше, чем проблем? Поделитесь мыслями, опытом, идеями?
использую specflow уже месяца три и то по причине того что он умеет делать репорты, кода конечно приходится больше городить, думаю тут по ситуации нужно смотреть …
Думать в первую очередь о том, что должен код делать, а не то как тестировать то, что уже написано
Использовать Arrange Act Assert или Given When Then (без ограничений Gherkin) внутри кода тестов для логического разделения
Использовать Fluent-assert’ы со всякими там Should.BeGreaterThan(42)
– это реально эффективный и классный подход
Запускаемая спецификация же, для меня, а точнее ее конкретные реализации по типу Cucumber или Specflow или другие – это излишки, которые отнимают время на поддержку, усложняют код, либо заставляют копи-пастить.
Результаты не стоят затраченного времени. За время, потраченное на написание на то, чтобы правильно передать параметры из Step в Step, можно написать свою библиотеку для создания красивых отчетов.
Ничего не имею против BDD-тулов, но нынешние реализации считаю очень ограниченными. Gherkin, в контексте конкретных реализаций, считаю очень ограничивающим языком.
У меня сложилось аналогичное мнение: что BDD - это больше о правильном подходе к автоматизации тестирования и обеспечению качества вообще.
На мой взгляд, применять BDD-фреймворки в том виде, в котором они предлагаются, эффективно в том случае, когда без их использования процесс именно так и поставлен и отлажен. Тогда применение такого фреймворка гармонично впишется в существующий процесс.
Когда же BDD пробуют применить ещё и для того, чтобы научиться правильно автоматизировать процесс обеспечения качества, то дополнительные сложности, которые такой фреймворк привносит, всё только портят.
То есть это к вопросу о том, “что же мы автоматизируем?”. Нельзя автоматизировать то, чего нет. Надо сначала организовать процесс, потом его автоматизировать, а не наоборот. Всё ИМХО.
Но хотелось бы услышать и истории успеха. Может быть кто-то может рассказать об успешном опыте применения Serenity (Thycidides) - какую пользу вы получаете от его использования, какие проблемы приходится решать при его использовании?
P.S. насчет выбора фреймворка по критерию “он умеет строить отчеты”, моё мнение такое: отчеты должен хорошо уметь строить CI-tool или даже TestManagement tool. Использовать для тестирования только фреймворк автоматизации для меня кажется дикостью. Потому что надо ж как-то ещё и ручное тестирование проводить. Поэтому я склоняюсь к тому, что должен быть Test Management Tool, где храняться как сценарии, так и отчеты о тестировании, а фреймворк автоматизации должен уметь с ним интегрироваться
Насколько я просек тему, то парадоксальным образом 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), а есть же ещё и модули (то есть если вы
автоматизируете манипуляции с ключами интенационализации Портала это
заведомо не все поймут в коде).
К порталу подключаются игрушки, а они все разные — допустим,
блэкджек, рулетка, покер, “однорукие бандиты”, лото, виртуальные
скачки…
testomat.io управление авто тестами
Выглядит симпатично. А как будет реализовываться user.clicks на элементы произвольной страницы?