Comments 32
Да, я раньше к cucumber'у тоже скептически относился. Но потом мы как раз использовали этот самый "лишний уровень" и все его преимущества для выноса на веб-платформу и написания там автотестов любым it-спецом. Все получилось и работает хорошо. Скорость написания и поддержки увеличились в разы.
И как "любые it-спецы"? Пишут автотесты? Очень часто просто есть требование для BDD прослойки от менеджмента, просто потому что, а пользоваться им никто так и не начинает, и по итогу core команда автоматизации поддерживает и свой фреймворк, и весь BDD уровень, и так же обычно это просто рудимент, на который тратится очень много времени, на поддержку, а "застрелить не поднялась рука"
Ага, пишут достаточно активно. Поначалу было сложно вводить это в продуктовые команды из-за естественного сопротивления, но сейчас уже всё ок. Основные пользователи продукта автоматизации это аналитики и ручные тестировщики — те it-спецы, которые точно знают, как должно быть правильно на проверках. BDD-уровень мы не поддерживаем — там уже нами разработаны все необходимые виды шагов для воплощения любого существующего сценария. Мы пилим и улучшаем кор, а сами автотесты в руках команд.
Ну как раз в очень больших организациях с недостатком квалифицированных (в плане разработки автотестов) специалистов такая история и может работать: узкий круг специалистов сделал конструктор, остальные "кликают мышкой", например, Альфа несколько лет назад хвалилась успехом своей Акиты на огурце.
Вызывает вопрос другое: зачем до этого автоматизаторы "сами для себя" писали на геркине? Чтобы что?.. (или это как раз были выпускники "диагональных" курсов, которые просто пользовались тем, чем умели?)
Раньше у нас был другой тип использования автоматизаторов — гибридный. Это когда люди находятся в продуктовых командах, пишут автотесты этой команды и еще тестируют руками новый функционал. У нас этот вариант совсем не взлетел, так как все ресурсы уходили на ручное тестирование, а автоматизация была по остаточному принципу. Потом с автоматизаторов сняли ручное тестирование, чтобы число автотестов увеличилось, но и это, в команде, работающей над быстрорастущим приложенем с редизайнами, давало КПД близкий к 0. Потом сели, подумали и сделали вот такой продукт, который уже отлично себя зарекомендовал.
Это я к тому, что, когда только внедрялся огурец, было совсем не до аккуратного выстраивания BDD. Поэтому это был булшит, который логировал методы и давал их чуть переиспользовать с выплывающем подсказом от cucumber. Не я внедрял, но зато работа с ним помогла допустить вариант с текущим решением.
Я оставлю этот комментарий как предостережение для тех, кто без должной кадровой, технической и финансовой подготовки рванет в "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится". И не дочитав до конца, вообще решит избавиться от выделеных автоматизаторов.
Удобство написания тестов, как, например, при применении продвинутого фреймворка, конечно снижает, трудозатраты на создание и сценарную модификацию тестов. Но, есть принципиальная проблема, что, разработчики пишут плохой тестовый код. Не потому что не могут, а потому что по разным причинам не уделяют этому достаточно времени, и потому что привносят в тестовый код практики из продуктового программирования, что в автоматизации не всегда уместно.
Вот пример вчерашний.
Пришел на новый проект. Проекту 4 года , гибкая разработка, разработчики делают всё, и автоматизацию в том числе. Результаты тестов нестабильные. Причем если для селениума это еще можно как-то понять, то нестабильные интеграционные тесты - это уже серьезно. Так вот, стал копать селениум тесты. Выяснил, в частности, что некоторые функции имеющие в названии слово "check", на самом деле возвращают булево значение. А при применении функции не всегда обернуты в ассерт. И получается стал ковырять нестабильность, починил ее, а потом вышел на то, что тест-то ложно-негативный. Потому что булевы значения просто улетают в пустоту. И у нас бажина в программе, которую этот тест не чуял незнамо сколько уже времени.
Потому что разработчик не может с той же въедливостью следить за тестовым кодом и его архитектурой как он может быть следит за продуктовым кодом. (Хотя, кого я обманываю там и продуктовый код тоже в таком же разболтаном состоянии). Отчасти это "эффект Простоквашино" - ...то лапы ломит, то хвост отваливается. Это когда над тестами работают все подряд, то, например, лепят кучу редундантных функций потому что разбираться в апи библиотеки функций нет времени.
А вот выделеный человек, он конечно чувствует свою полную ответственность, и понимает что удобно делает в первую очередь себе. И у него будет все по полочкам. И каждую функцию он будет знать по имени.
Но, конечно, любой автоматизатор, в конце концов, из всякой свалки бессвязного хлама, хочет сделать супермаркет. И вот тогда... в этом счастливом будущем, возможно разработчики будут просто набирать тесты, из готовых модулей (пусть это будут шаги featue-файла - не важно), а имплементацией этих модулей и их качеством будет заниматься автоматизатор.
Ну и что еще я заметил, это то что когда тестовый код пишут разработчики, то код тестов часто напоминает по стилю продуктовый код. А в автоматизации наоборот, хорошо иметь незамудреный код. Без выкрутасов. Потому что 60-80% времени автоматизатора уходит на поддержку тестов. Нужно быстро воспроизвести, зарепортить, или починить, не задев ничего другого, и бежать дальше.
Т.е. к тестовому коду разработчики относятся так, как будто этот код не будучи продуктовым заслуживает меньшего усердия. А на самом деле, тестовый код требует большего усердия. Если в продукте функционал работает и ладно, то в тестировании - тест зеленый и ладно - не ладно. Он может быть не по делу зеленый. И нужно пройти по нему, убедиться, что он не ложно-отрицательный и содержит только нужные проверки. И что, напротив, не содержит не относящихся к контексту тестового сценария проверок и шагов и так далее. Чтобы писать хороший тестовый код нужна дисциплина. А у разработчика психология другая. Они пытаются сэкономить силы, а это выливается в некачественные тесты.
П.С.:
Я бы даже за сценариями следил, которые разработчики пишут, потому что некоторые считают, что слепить последовательность, которая описывает самую длинную цепочку действий, безотностительно к пользовательским сценариям - клевая идея. Ну или, если с фантазией похуже, то переключать чекбокс двадцать пять раз подряд - а вдруг отвалится.
Тема довольно холиварная, но я с вами соглашусь — разработчики имеют другую психологию, нежели АТ и ФТ. Моя же команда состоит из людей, которые автоматизаторы, выросшие из кузни качества продукта. Поэтому и не было проблем в глубинном понимании всех болей тестирования, чтобы получился ортодоксальный продукт, прежде всего для ФТ. Мы разработчики лишь с той точки зрения, что пишем нормальный код и на 80% занимаемся кором. В дополнение мы собираем постоянную обратную связь, чтобы слушать и слышать наших ключевых пользователей — ФТ. Люди же, находящиеся на позиции классических разработчиков и которым дали сделать продукт автоматизации, часто срезают углы не от хорошей жизни, а лишь потому, что с них не снимают в это время продуктовую разработку.
Так как в нашей компании специалисты всех направлений имеют возможность писать автотесты на нашем продукте, то ревью итога все равно остается за ФТ. Они отвечают за качество продукта и за то как он оттестирован. Поэтому ситуации, что кто-то накидал длинную макаронину, которая что-то много того и не того проверяет — невозможна. У нас каждый автотест проверяет 100% тест-кейса.
Я искренне надеюсь, что те менеджеры, которые говорят "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится" имеют достаточно опыта в нашей индустрии, чтобы принять это решение взвешенно.
Могу сказать, что в данном случае организация АТ по сути исправляла ошибки по организации работ ФТ - не было общей базы и артефактория по тестам, не было координации работ по пониманию важности и возврата инвестиций от АТ к ФТ :)
Введение BDD - всегда дополнительный слой работ и всегда усложнение тестов. При наличии нормальной базы и наполнения беклога АТ я в реальности не видел чтобы это работало, ведь чтоб BDD взлетело - нужно чтобы ВСЕ писали и ВСЕ поддерживали - это титанический труд по контролю
Резюме: статья явно приукрашивает :) история хорошая - из разряда "мы сделали правильно в сложных условиях". но по сути - смысла реального в BDD не особо есть в случае нормальной работы ФТ/АТ. Тут явно ощущается некая продажа менеджменту его как серебряной пули :)
Как обычно в нашем ИТ - забиваем мелкие сапожные гвоздики кувалдой.
P.S. Статья не убеждает что это в реальности работает и помогает деливери.
Очень рад, что вам понравилась моя история :)
Мы нескончаемо (как и все спецы качества в других компаниях) работаем над проработкой общей базы и артифактория по тестам. Понимание важности очень трудно показывать при смене классического метода подхода к структуре автоматизации — тут действительно были сложности, но сейчас уже есть все метрики, чтобы сказать, что такой подход для нас гораздо удачнее.
Работы над слоем BDD мы проделали в самом начале нашего пути переписывания кора. Сделали это основательно, чтобы не тратить на это время после. У нас теперь действительно все пишут и поддерживают. Это не умножение работы, а ее распределение, со снижением узкого горлышка AT и ФТ. Команда сама решает, кто будет писать автотесты в конкретный момент времени, а затем сама несет за них ответственность.
Ничего не преукрашивал, тут просто наш кейс с итогом, что взлетело. А BDD у нас идеально лег под вынос всех параметризированных шагов в webIDE и максимальному снижению планки входа в написание автотестов — без настроек и танцев с бубном.
Может, факт того, что наш ТТМ сократился на день за счет новых автотестов, убедит вас в том, что и с деливери у нас всё ок )
Ну собственно я ж написал про приукрашивание со стороны. А вообще - любой рассказ всегда остаётся рассказом без метрик, поэтому я акцентировал внимание, что статья не убеждает. Чиселки-то где? :)
Сколько проектов не видел (а видел много) - BDD только вносит проблемы. Хотя это и удобная штука для выноса написания самих тестов "вширь" из отдела АТ, я б не сказал, ИМХО, что это в реальности помогает с написанием тестов по их качеству. Количественно - возможно...
И в очередной раз вместо нормального стека тестеры берут старый никому ненужный rest assured, да и вместо нормального тестового фреймворка junit 5, был взят testng. И ещё, вы на полном серьёзе используете чистый селениум?
Как же rest assured может быть никому не нужен, если все его используют для API-автотестов. Вот, например, можно взять https://mvnrepository.com/tags/rest — он там номер 1. Библиотека существует уже больше 7 лет с постоянными обновлениями и пишется в очень приятной флюентинтерфейсной манере — чистый кайф.
Выбор junit 5 и testng окончательно стал лишь вкусовщиной, так как они оба отличные фреймворки с идентичными возможностями. Мое личное предпочтение — TestNG.
По селениуму согласен, что есть Selenide и другие обертки, начинающиеся на Selen..., но для нас это лишь крошечный слой, не влияющий на скорость выполнения автотестов. Основной движок UI-автотестов у нас на Atlas.
Какие по вашему мнению есть альтернативы rest assured? Он развивается, уже работает в связке со спринг. Да и junit это основа тестирования на java, testng просто добавляет работу с тестовыми данными более удобную. Селенид хороший, но тянет слишком много лишних зависимостей, легче написать свою обертку над чистым селениумом. Есть playwright, тоже интересный, не требует установки браузера и можно вебкит тестировать, но у него свои особенности
И вот как теперь жить? Мой тезка (по имени и фамилии) топит за Геркин... А я - активно топлю против...
Несколько сумбурно поясню свою позицию:
Мы пытаемся хороший код на хорошем языке программирования заменить очень урезанным языком описания тест кейсов (Gerkin).
Основная фишка данного подхода - «любая домохозяйка может написать тест». Проблема в том, что «домохозяйки» тесты не пишут - обычно пишут тесты все-равно разработчики или тестировщики.
А им удобнее пользоваться полнофункциональным языком программирования.
Хороший фреймворк для тестов требует довольно аккуратной поддержки со стороны разработчиков.
Я видел ситуации когда BDD тесты превращались в огромную плохо поддерживаемую портянку. По которой невозможно навигироваться с помощью IDE, рефакторить их тоже нет никакой возможности.
Часто разработчики, которые делают фичу делают что-то маленькое для поддержки в тестах и те кто вынужден писать автоматизированные тесткейсы - пишут их и мучаются, т.к. они не в состоянии поменять инфраструктуру (ну или цикл изменения этой инфраструктуры довольно длинный - проще написать как есть).
Мой путь - писать тесты разработчиками. Они пишут тесты на их языке программирования. Причем все возможности современных IDE им помогают. Если что-то больно (неудобно) писать - сам разработчик мучается и это именно тот человек который может что-то с этим сделать.
Да, на разработку фич требуется больше времени разработчиков. Но, как мне кажется, на длительном промежутке времени оно может окупаться.
Касательно Gerkin тестов - они наверное могут быть, но не надо их ставить во главу угла. Это инструмент, у которого есть плюсы и минусы. Нужно аккуратно думать прежде чем внедрять его.
Прошу понять, что я не топлю за геркин, это лишь средство достижения цели. А цель была именно дать возможность писать тесты главным людям, имеющим знания ожидаемого поведения всей системы. Тест-кейсы не всегда показывают всю глубину необходимых проверок, поэтому автоматизаторы или разработчики, которые пишут автотесты по ним, часто сужают проверку, нежели ручные тестировщики, тем самым снижая качество продукта. Плюс добавляется игра в сломанный телефон с аналитиками про то, а как должно было быть. Поэтому мы и выпилили автоматизаторов из процесса написания автотестов и дали им заниматься фреймом.
Мое мнение, что если вы хотите дать своим продуктовым разработчикам ещё и автотесты писать, то для этого должны быть максимальные условия с точки зрения документации, тест-кейсов и процессов. Плюс давать проверять тому же человеку, что и изобрел что-то — это антипаттерн тестирования. Ведь все мы, как известно, не видим в своем глазу бревна.
Кому писать авто тесты - может быть вопросом узкого звена в цепи разработки.
У нас это тестировщики. И поэтому автотесты пишут разработчики.
Но фраза про то, что писать автотесты на свой код плохо, натолкнула меня на мысль, то автотесты к функционалу, реализованного одним разработчиком, должен писать другой. Это ещё будет способствовать узнаванию функционала.
Спасибо за идею.
А у меня простой вопрос. Как выглядит, например, какой-нибудь post запрос на геркире, чтобы можно было понять какой json он засылает?
Вот пример, как это сделано у нас:
Тут 2 параметра: эндпоинт и тип рестового метода. А в DataTable заполнение ключ-значение json. По-умолчанию все, кроме true/false, является типом String. Если нужно что-то другое, то можно воспользоваться в value допками, типа "Integer:". При запуске запрос виден полностью с урлом, хедерами и json в привычном виде:
Ну это плоский json, такие редко бывают. А если вложенность? Или списки? Ну, например:
```json
{
"field1": 2,
"field2: {
"field21": "value21",
"field22": "value22"
},
"list": [
{
"list1": "listvalue"1
}
]
}
```
ну и так далее.
Вложенность у нас делается через точку, а списки так и остаются, так как у нас бывают редко:
Но если вы отправляете очень объемные рестовые запросы, то не стоит, как мне кажется, их засовывать в геркин полностью, а то это сильно ударит по читаемости автотестов. Советую использовать что-то типа FreeMarker'а для создания запросов-шаблонов, в которых большая часть значений будет статична(и только изменяемая часть станет тем самым DataTable), а ссылаться в самом шаге на шаблон по его названию *.json. Мы так сделали для мокирования, так как там нужно ставить заглушку на ответ, который почти всегда объемный.
Понятно. Похоже на TOML чем-то. Ну, так себе. :)) А почему не через Docstring тогда?
Я встречал TOML только в инвентарниках Ansible. По мне не похоже )
По Docstring не понял, как его тут можно применить, но с удовольствием бы послушал ваши мысли по этому поводу, хоть у нас и Java, а не Python.
Не понял причём тут python? Я имел в виду это https://cucumber.io/docs/gherkin/reference/ тут поиском docstrings. В таком случае можно писать json как есть без всяких табличных извращений. :)
А, понял про что речь теперь. Да, вещь хорошая, но размер такого шага увеличится процентов на 20 из-за переносов и скобок. Читаемость в минимальное число экранов снизится, что влияет на быстрый анализ автотеста глазами. Для нас DataTable хороший и лаконичный формат, который себя хорошо зарекомендовал и исправно работает.
Прям сморю и слезы на глаза наворачиваются. Бэк-энд тесты можно писать во время разработки, с большоц скоростью, например, на Java+JUnit5+restAssured(или Spring Boot). А с этим огурцом, надо сохранять промежуточные результаты, рефакторить жутко не удобно и тд. Никогда не используйте Cukumber для бэка. Совет от автоматизатора с опытом 8 лет и видавшим кучу проектов. В автотестиррование пришла не из "ручников", образование айтишное.
Стек для бэкенда у вас выбран отличный, сам такой бы выбрал, но заменил бы JUnit5 на TestNG. Более того движок серверных тестов у нас на этом же стеке, если снова посмотреть на текст статьи. Cucumber у нас лишь для того, чтобы написание автотестов было удобно вынести в браузер - через webIDE. Так получается, что сервер - это не единственная платформа, требующая автоматизации у нас, а есть еще 2 мобильные платформы и веб. Таким образом наш проект позволяет в едином пространстве писать 4 вида автотестов без всяких настроек. Если вы занимаетесь только автоматизацией бэкенда, то можно и обойтись фреймами, работающими только с кодом. Для этого я и написал финальную часть "Не повторяйте это дома, трюк выполнен подготовленными специалистами" - где я призываю все хорошенько обдумать, ведь моя статья не руководство к действию, а кейс.
А чем testNG лучше Junit5? Особенно с учётом того, что TestNG не шибко активно развивается.
Я начинал писать на TestNG в 2016м. Тогда был JUnit4, который не только уступал в функциональности, но и уже 2 года, к тому времени, не выпускал обновления. А сейчас они оба имеют аналогичные возможности, оба развиваются и стали лишь делом вкуса и привычки. Более того JUnit5 себя отлично зарекомендовал и теперь является тоже отличным выбором.
В 2023 пора уже юзать ChatGPT для написания аатотестов.
Перестаньте писать автотесты силами автоматизаторов