testomat.io управление авто тестамиЗдравствуйте коллеги.
От нового проджекта прилетела хотелка от которой невозможно на словах отказаться (аргументы что хочет заказчик и его начальинк) переходить на BDD и конкретно Cucumber.
Беда в том что давно существует фреймворк, в котором реализованно неслабое покрытие тестами. Успешно используется Allure, тесты бегают паралельно и вполне стабильно, под новый функционал пишутся новые кейсы.
Другая беда что из команды нет никого кто работал бы с Cucumber, аналитик будет выделен из команды и тоже не в курсе как писать на геркине.
Есть ли у кого аргументы за и против (ссылки на ресурсы итд)? Сравнительные таблицы или еще что-то?
) BDD это язык. Это новый язык, его реализовать вам, а не сделают за вас. В любом случае это overhead — “нагрузка”: вы создаете второй, “человеческий” язык для описания того что и так будет описано кодом. Я видел отзывы что это может хорошо работать, но лично видел только как это работает плохо.
) Нужен “централизованый орган”, который этот язык будет стандартизировать и поддерживать. Например, из статьи о BDD в “Тинькофф”: “Мы остановились на описании полной иерархии страниц и их элементов…” — это полное описание живет и работает где-то централизованной группой.
Если вы сразу видите что полное описание страниц/экранов и элементов может потянуть на много-много-много страниц и времени, то скорее всего затрат на BDD у вас будет больше чем пользы.
) BDD лишь ограниченно соответствует алгоритмическим языкам. Это “линейный” язык (сценарии линейны), без условных операторов, циклов и пр. Есть мнение что так и надо, есть мнение что это далеко не всегда хорошо (я придерживаюсь последнего). Т.е. нужно придумывать какому коду будут соответствовать фразы BDD, как это реализовать.
) Этот язык требует обучения и коммуникаций. Нельзя просто так взять и писать на Геркине что попало — сначало надо посмотреть и согласовать что уже написано, как и в каких терминах оно написано, всяко стремиться к повторному использованию (reuse). Если у вас нет много повторного использования, BDD, опять же, может значить для вас больше проблем чем решений.
) Если у вас, скажем, всего два-три автоматизатора, вполне возможно что они в этом загрузнут по уши (это было причиной отказа от BDD в тех случаях где я это видел).
) BDD нужна техническая поддержка, и значительная (в вышеупомянутой статье от Тинькоффа описано сколько им пришлось дорабатывать — свой плагин, база локаторов (языка), база BBD-фраз (видна на демо-анимациях), база тестовых данных…
Для небольшой команды усилия по BDD скорее всего того не стоят: они значительны, а эффект может оказаться меньше потраченных усилий (также см. ниже).
) Если ваша продуктовая палитра содержит “много всего”, например веб-портал, пару мобильных приложений, веб-приложение отличное от портала… — вам будет тяжело работать с BDD, потому что нужно много-много языковых элементов.
) BDD не обязательно ускоряет, или опережает. Цитируя опять же статью от Тинькоффа, “Классический вариант {x}DD, когда изначально пишутся все тесты, и только потом начинается непосредственная разработка, в изначальных наших условиях сильно повлиял бы на наш быстрый релизный цикл, что для банковских сервисов непозволительная роскошь.”
Если вам критично что-то зарелизить быстро, вам нужна либо мощная поддержка которая будет быстро писать переводы кода на BDD язык, либо BDD вам для быстрого релиза не нужно. Если вы делаете новый функционал, который надо одновременно исследовать и тестировать как он работает (у меня такое было вот недавно) — Вам BDD тоже вряд ли нужен.
Опыт из которого это написано: три проекта где пытались внедрять BDD.
- Очень сложная и разноплановая предметная область, сотни разных приложений и экранов. Туда вообще было бы лучше не соваться с BDD. Итого: BDD выкинуто.
- Реализация через BDD (Specflow) формально работала, но ничем не помогла. Вина тут скорее была не BDD а сложности тестируемой системы и проблем с ее аппаратной, но особенно програмной частью (свой проприетарный сервер, своеобразная реализация с использованием Appium). Не расширив особо ни фич ни покрытия, проект закрылся.
- Опять таки разноплановая предметная область, хотя и не такая архисложная как в случае 1, но большая. Поддержка BDD требовала значительных отдельных ресурсов программистов, BDD-описания кейсов выходили большими, сложными, непонятными. На него перестали выделять ресурсы и благополучно похоронили. Т.е. хотели “кейсы на BDD читабельные для всех”, а получилось “ни для кого”.
Т.е. если у вас есть готовое и бегающее решение, всяко советую от своего опыта 3 лет наблюдений BBD-неудач (из 10 лет опыта в тестировании) всяко отбиваться от BDD и не брать этих сложностей себе на голову.
Начальству же перевести то, что я написал (новый язык, поддержка, сложности) и сказать что за это будет заплачено временем на разработку и большими деньгами. А результат будет только в том случае, если новые экраны будут похожи на старые и таким образом можно будет быстро переориентировать код BDD под повторное использование и делать такие же или почти такие же сценарии как напишутся первые.
1 лайк
А в чём проблема добавить еще 1 слой под БДД?
Что-то не видно постановки проблемы в ОП. Просто берете и объясняете манагерам, что: 1) нету экспертизы 2) есть большой легаси фреймворк, соотв. “перевод” его на Кукумбер будет стоить много времени и денег. Заказчик с менеджером готовы подождать пару месяцев, пока это будет делаться (в ущерб поддержке существующего фреймворка, написания новых тестов итд)? Думаю, нет. Если готовы (маловероятный сценарий), то открываете гугол и вперед.
На этом форуме уже 100500 тем с обсуждением BDD/неBDD, просто поищите по тегу bdd. Например, вот: Каковы преимущества и недостатки BDD подхода написания тестов?
P.S. Насчет кукумбера:
“Cucumber is not a tool for testing software. It is a tool for testing people’s understanding of how software (yet to be written) should behave.”
Что значит еще 1 слой?
По слоям у нас так:
Сьюты (testNG) => Тесты => Степы (Allure) как большие, так и мелкие => Пейджи с блоками
На сколько я понимаю встраивание происходит на уровне уничтожения тестов и распрямления степов от ветвлений и циклов…
В моем случае BDD на проекте уже решенный вопрос.
Обсуждаем, при наличие достаточных аргументов, вопрос внедрения огурцов в существующий фреймворк, с хорошими отчетами, приличным покрытием регрессией итд.
Следует учесть то что регрессия легаси писалась 1.5 года и регрессия нового функционала уже пишется менее опытными ребятами еще 1.5 года.
Степы останутся, только теперь они будут на Геркине. Между степами и пейджами придется добавить методы реализации Геркина и вспомогательные: каждый степ геркина это свой отдельный метод. Если нельзя уложить логику в один геркиновский степ, нужны дополнительные методы.
Если у вас есть передача состояния между тестами, то это придется реализовывать мимо Геркина.
Сочувствую.
Тоесть степы будут мягко говоря порефакторены в зависимости от уровня абстракции в Аксептенс Критериях на гиркине?
Если есть регрессия готовая то ее можно “выбросить” в другую репу и из нее гонять, потому как переиспользовать степы и там и там нереально?
Если есть возможность, то лучше пилите новый проект и перетягивайте в него старые тесты. С одной стороны дольше и дороже, зато прозрачнее и проще. Тем более, что старую тестовую модель было бы неплохо и пересмотреть и актуализировать. К тому же можно забабахать рефакторинг о котором давно мечтали, но не было времени сесть и сделать. За пару лет и вы стали мудрее и требования менялись не раз. Наверняка, остались у вас места от которых хотелось бы избавится, но не хватало времени. А так можете запилить по новой с уже более лучшим пониманием своего проекта, как будут использоваться тесты и т.д. А за счет того, что тесты будут «мигрироваться» постепенно, то проще будет следить и понимать состояние дел и проводить дальнейшее планирование работ. К тому же останется чистый и не тронутый старый проект к которому всегда можно вернуться назад. Минус - поддержка двух проектов какое-то время и способ как их запускать и смотреть в общем отчете, если нет каких-то алм систем, а только дженкинс и аллюра.
1 лайк
Второй проект работаю с БДД. Вначале был на Java+Cucumber+Junit, теперь на c#+SpecFlow+NUnit. Начинал писать с 0 тесты. Плюс, что понятно, что падает, на каком степе, все степы разделены по page обьектам. Allure смог недавно прицепить в .Net только. Но знаю, что есть и Allure for Cucumber.
По поводу вашей ситуации, думаю проще будет начать новый проект. Перекинуть туда PageObjects, и брать часть методов и вставлять в степы.
Это будет вам больно и неприятно, и неизвестно, принесет ли внедрение профитов. Как тут выше советуют - лучше создать отдельный проект и новые тесты писать там, постепенно перетаскивая и старые тесты.
ЗЫ:
А уж читая примеры на Cucumber JVM, я вспоминаю как это это сделано на Cucumber JS (там тоже есть свои боли, но по крайней мере степы писать гораздо проще).
Сравните код для Cucumber JVM:
@Given("I have {int} cukes in my {string}")
public void some_cukes(int howMany, String what)
// some code
}
С этим же кодом для JS
Then(/^I have (\d+) cukes in my (.*)$/, function (howMany, what) {
// some code
}
Как минимум, для Cucumber JVM придется придумывать метод some_cukes, для того же JS - степом будет функция Then() с переданной ей регуляркой. Пишется гораздо быстрее и легче (текст из Gherkin легко ложится в код).
(в качестве небольшого оффтопа) В Cucumber-JVM не так давно завезли лямбды, так что там тоже можно писать методы как в JS (непонятно правда, зачем, и какой от этого профит, но тем не менее):
Then("^I have (\\d+) cukes in my (.*)$", (Integer howMany, String what) -> {
// some code
});
3 лайка
Это вообще не слои.
У вас есть слой пейдж обжекта, скорей всего слой степов (алюр) Сверху накладываете еще 1 слой геркина и всё, то что написано у вас в степах Алюра просто напишите на геркине.
У нас серенити и на 1 слой больше. Слой пейджей -> слой степов серенитики -> слой степов на jBehave -> слой на геркине.
Единственная польза от внедрения Cucumber на проекте - это то, что понятие тест кейс существует в единственном экземпляре в виде gherkin сценария. Если у вас по прежнему останется тест кейс в какой либо тест трекинговой системе и ещё один в виде gherkin сценария, то смысла очень мало.
Незначительный профит можно получить если вы планируете процедуру приемки автотестов тестировщиками - т.е. процедура когда тестировщик мануальный убеждается что автотест выполняет всё как задумано - на gherkin всё понятней.
Если переходить, то как советовали ниже - начинайте с нуля и мигрируйте.
1 лайк
Не знаю как на Java, но на C# в Specflow можно использовать любой тестовый фреймворк для генерации и выполнения тестов, хотя сами тесты пишутся на геркине. Потом можно просто запустить таким образом:
nunit3-console bin\Debug\UnitTestProject2.dll
При таком подходе вы можете дописывать тесты в новом формате в существующий фреймворк, переиспользуя всю инфраструктуру(Page Objects…)
1 лайк
Что бы понять подходит вам или нет этот подход надо просто попробовать. Это ведь займет не так уж много времени. И потом вы сами сможете предоставить отчет начальству со всеми плюсами и минусами. Боятся внедрять что-то новое это путь в никуда… Со стороны заказчика преимущества этого подхода очевидны он сможет прочесть и понять что вы делаете.
Если начальству нужны только красивые/понятные отчеты, и ничего более - лучше реализовать нормальное логирование в отчете, нежели чем внедрять BDD.
1 лайк
Как насчет такого варианта :
@Slf4j
public class StepLog {
@Step("Given {stepDescription}")
public static void Given(String stepDescription) {
log.info("Given " + stepDescription);
}
@Step("When {stepDescription}")
public static void When(String stepDescription) {
log.info("When " + stepDescription);
}
@Step("Then {stepDescription}")
public static void Then(String stepDescription) {
log.info("Then " + stepDescription);
}
@Step("And {stepDescription}")
public static void And(String stepDescription) {
log.info("And " + stepDescription);
}
@Step("I {stepDescription}")
public static void I(String stepDescription) {
log.info("I " + stepDescription);
}
}
В тестах пишете логи в подобном формате и показываете заказчику отчет в “BDD” style. Или они хотят писать тоже ?
1 лайк
Не сказал бы что это что-то новое) Сделать пилот не сложно, но при попытке его интегрировать в существующий фреймворк только на подготовку уйдет прорва времени, при очень ограниченных ресурсах (этак 0.5 меня) 
Логирование (и репортирование происходят по @Step, в лог попадает начало и конец выполнения степа) и так нормальное по это дело и писали фреймворк, с логированием (и репортированием) степов чуть ли не до кликов. Новый начальник пришел и тулит отчет из кукумбера, как “крутой” сравнивать его с аллюровским вообще смешно.