Соробан, инструмент для проверки калькулятора на счётах (на самом деле — два интерфейса, для коротких расчётов тактильный был удобнее)
У нас была классическая история: разработчики разрабатывают, автоматизаторы пишут тесты. Банковское приложение, backend, web, ios и android платформы, очень много схожих тест-кейсов. В какой-то момент сама скорость появления новых фич сильно превысила даже теоретическую возможность покрывать их автотестами. Можно было линейно масштабировать отдел (по моим расчётам, нужно было ещё 12 человек), а можно было попробовать понять, как всё это поменять.
Я знал, что автоматизаторы пишут четыре разных теста для одного и того же кейса для четырёх разных платформ, и поначалу полагал, что можно слегка уменьшить разрыв, соединив часть историй в какой-то единый проект. Но когда мы начали разбираться в деталях, что же там происходило, выяснилось, что КПД можно повысить очень и очень сильно.
Дело вот в чём: ручное тестирование — это один из способов входа в ИТ. Дальше в процессе развития навыков программирования добавляется возможность стать джуном автоматизации. Большинство этих джунов учат на курсах три фреймворка по диагонали и дальше считают себя профессионалами. Однако действительно хороший автоматизатор не ценится в достаточной мере, поэтому senior-автоматизатор — это мифическое существо, схожее с единорогом. Эти сказочные существа растворяются, уходя в разработчики ПО. Закономерный итог: слабая архитектура фреймворка (точнее, её отсутствие), почти нет переиспользования кода, каждый отдельный автотест пишется чуть ли не с нуля.
Поэтому в итоге мы отдали весь процесс автоматизации горстке единорогов. Отдельной команде.
Решение достаточно спорное и с экономической, и с логической точки зрения, но сейчас расскажу, что получилось.
Ключевая проблема
Автотесты не успевали за появлением функциональности. Можно нанять больше людей, тогда можно будет успевать. Но «количество» не равно «качество». В итоге мы зашли в эту историю силами нашей команды единорогов, чтобы привнести нормальное видение архитектуры и зрелые подходы, и для начала вообще проанализировать проблему, сформулировать задачу и выбрать максимально эффективное решение.
Главной причиной было неиспользование всей силы BDD-языка. Для примера — язык gherkin автоматизаторы использовали как нечто рудиментарное, которое всего лишь немного объясняло свой метод, находящийся под ним. Как логирование. Я не сильно упрощу реальность, если скажу, что для шагов «сложить 2 и 2» и «сложить 2 и 3» использовались разные методы их реализации, вместо того чтобы воспользоваться параметризацией.
Идея была в том, чтобы сделать подобные ситуации работающими через таблицы DataTable и параметризацию gherkin-шагов, чтобы каждый отдельный шаг был мощным и гибким сам по себе. В итоге если всё правильно сделать, то пользователи продукта автоматизации некоторое время учили бы наш каталог с видами шагов, а дальше, к моменту написания четвёртого автотеста, уже знали бы, что делать, потому что использовали бы уже 80% всех их типов. Ключевая фишка была бы в том, что новый автотест после этого можно и писать, и актуализировать со скоростью света.
Кратко о развитии автоматизатора
Хороший автоматизатор — это разработчик, который разбирается в тестировании, всех сопутствующих настройках и технологиях. Чтобы было понятнее, я сейчас разобью процесс развития автоматизатора на этапы.
На первом этапе нужно следовать правилам, выполнять инструкции и повторять. В разрезе автотестирования это уровень, когда вы приходите в автоматизацию из ручного тестирования и пишете автотесты по хорошо описанным тест-кейсам. Вы не нуждаетесь в умениях, больших, чем язык программирования уровня junior. Плюс менторство и небольшое внутреннее обучение для понимания специфики работы с нужными фрейморками (обычно лекция часа на три).
Следующий этап требует более глубокого понимания выполняемых действий. Нужно вникать в логический смысл автоматизации, чтобы выйти из-под «опеки» ментора. В автотестировании на этом этапе находятся люди, которые уже на протяжении нескольких лет писали автотесты и повстречали на своём пути много различных проблем, решать которые брались другие специалисты: старшие автоматизаторы или разработчики. После этого к ним пришло осознание, что на этот процесс можно влиять самим, и они пошли подтягивать уровень до middle в языке программирования. С этим арсеналом они уже начинают сами подкручивать фреймворк, не прося помощи на каждый чих, но продолжая писать автотесты по тест-кейсам.
Далее идут специалисты, набившие множество шишек и тем самым получившие много опыта. Они пишут автотесты, но редко. Основное своё время они отдают развитию фреймворка. Фреймворк как ядро автоматизации является системой с высокими рисками. Поэтому туда не пускают всех подряд, а только тех, кто зарекомендовал себя в глубоком знании всего проекта автоматизации.
И наконец, последний этап заключается в исследовании и экспериментировании, с поиском новых и неординарных решений. Это этап, на котором находятся люди, имеющие много опыта в автоматизации, использовании разных фреймворков и написании автотестов. У них есть понимание, как построить автоматизацию, если её вообще нет. Они могут дать экспертную оценку по использованию той или иной технологии — её плюсы и минусы. Общий взгляд на автоматизацию у них уже чуть со стороны, со стороны её использования. Часто бывает так, что их ставят на позицию тимлидов отдела автоматизации тестирования.
Именно набор специалистов последних двух уровней поможет создать продукт автоматизации. Притом обязательным в этой схеме является наличие креативных специалистов. Совместно они способны сделать продукт под ключ, чтобы можно было писать автотесты легко и быстро.
Из таких людей мне удалось собрать команду для создания нашего продукта автоматизации тестирования.
Детали
Пару слов о проекте. Наш продукт — это мобильное приложение для физических лиц, клиентов Банка Хоум Кредит. Оно состоит из четырёх платформ, и все они должны быть протестированы. Команда автоматизации сейчас состоит из пяти человек. Над поставкой этого продукта пользователю работают чуть больше 100 человек, разбитые на Agile-команды.
Одной из задач было решение проблемы бесконечно долгого найма высококвалифицированных автоматизаторов для написания и поддержки автотестов. То есть обычно их могут писать только высококвалифицированные автоматизаторы из-за высокого порога вхождения. И чтобы сломать эту традицию, я решил зайти с другой стороны — сделать сложный проект внутри, но простой снаружи для привлечения к написанию автотестов специалистов разных областей: разработчиков, функциональных тестировщиков, аналитиков и всех остальных.
Первым этапом мы создали проект, в котором были все необходимые модули по платформам плюс общий модуль. Этот модуль был создан для пересекающихся шагов и утилит. Его цель — хранить методы шагов, которые используются на всех платформах. Примерами такого являются работа с базой данных, арифметические действия и различные интеграции.
Единый проект для всех платформ — нечастый подход. Чаще встречается объединение на уровне UI/не-UI, но у нас именно всё и сразу. А вот запуски идут через использования сборщиком только одной пары модулей, например общий и мобильный или общий и веб.
На этой стадии очень важно было найти людей, кто реально очень хорошо разбирается в подобных типах проектов и может рассказать с высоты своего опыта, что взлетит, а что нет. Наняли консультантов, они очень быстро развеяли некоторые наши иллюзии. И заодно показали, что стек должен быть именно такой, исходя из нашей подготовки: часть компонентов можно было бы выбрать и лучше, но тут ещё было важно, в чём команда действительно разбиралась или могла быстро разобраться.
Технологии выбрали такие:
- Общее: Java, Cucumber, Wiremock
- Backend: TestNG, RestAssured
- Web: Selenium, Atlas
- Android, iOS: Appium, Atlas
Дальше нам требовалось аналитически пройтись по всем тест-кейсам и выделить типизированные шаги. Например, поиск нужного клиента, работа с экранами, rest-запросы, обработка ответов, мокирование и многое другое. Итого у нас получилось порядка 20 таких шагов. Далее во всём этом многообразии нужно было проработать все ответвления и создать заготовки для супершагов. Они должны были использовать все преимущества gherkin-языка, а именно возможность их параметризировать и использовать DataTable. Гибкость и универсальность позволяет мне называть их «супер», не более того.
На этой стадии ушла вся подготовительная аналитика. Мы остановились, осмотрелись, сравнили тест-кейсы, выделили различия и сделали всё это параметризированным. Код, по сути, повторялся очень часто.
Следующий этап — документирование и планомерная реализация всех супершагов с постоянным сбором обратной связи будущих пользователей.
После реализации
Нужны были ответы на стратегические вопросы: а как начать писать автотесты любому сотруднику и нужно ли устанавливать кучу дополнительного ПО для их запуска?
Ответы звучали не очень просто и совсем не дружелюбно для пользователя продукта автоматизации тестирования. Для решения этих вопросов нужен был общедоступный фронт, где было бы удобно писать, отлаживать и отслеживать результаты прогонов автотестов.
В банке создали свою WebIDE с усечённым функционалом, где можно:
- Писать автотесты на языке gherkin с подсветами параметров шага и возможностью выбора вариантов шагов.
- Перемещаться по дереву всех автотестов.
- Запускать автотесты во временной ветке на удалённом сервере (привязка к джобе в jenkins).
- Следить за историей запусков со всеми ссылками на отчёты.
- Создавать пулреквест на вливание в master.
- Работать в своей локальной сессии без влияния на других.
- Использовать дополнительные папки — связующие с проектом для манёвра.
За прохождением теста можно следить на web-портале с отчётами. Для backend это логи, а для UI это логи и скриншоты экранов.
После реализации мы провели серию воркшопов по обучению всех команд, как этим продуктом пользоваться. На нём в формате реального времени показали всю лёгкость написания автотестов любой из платформ без использования чего-либо дополнительного, кроме браузера.
Всё ещё стояла проблема: а как нам добавлять новые элементы UI-экранов в проект автоматизации, ведь вариант с использованием xpath прямо в feature-файлах сильно ударил бы по их читаемости. Мы воспользовались дополнительными папками в WebIDE и создали систему кодогенерации на основе json-файлов вида:
После написания в своей сессии WebIDE подобного файла можно сразу использовать эти элементы в текстовом эквиваленте:
При таком подходе команды сами следят, в каком состоянии находятся их автотесты через ночные запуски, делают правки без использования команды автоматизации, пишут и, что более важно, поддерживают автотесты очень простым и удобным способом. В это же время команда автоматизации работает над снижением внутренних рисков продукта автоматизации, ускоряет его и поддерживает работоспособность через ядро проекта.
Не повторяйте это дома, трюк выполнен подготовленными специалистами
Если у вас появилось желание сделать вышесказанное у себя, то не спешите. Наш способ подходит, конечно же, не всем. Например, если у вас маленький проект или изменения на нём бывают редко, то наш способ может оказаться для вас излишне сложным. Но вот если у вас энтерпрайз-многомодульная система с постоянными изменениями в дизайне, то наш опыт вполне мог бы оказаться для вас полезным.
Проще всего посчитать целесообразность по экономике: большое количество автоматизаторов тестирования по сумме зарплат превышало сумму зарплат наших пяти высококвалифицированных разработчиков технической команды автоматизации.
Дальше стоит оценить психологическое сопротивление: такой подход всё же не самый стандартный и придётся долго убеждать всех вокруг, что это может сработать. Это рождает много новых рисков: стабильно проще людей научить перекладывать на конвейере запчасти, чем автоматизировать весь процесс.
Но в целом автоматизация по идее где-то в лучшем мире и должна работать именно так — когда она сама в порядке, красивая и эффективная.
Комментарии (32)
lxsmkv
00.00.0000 00:00+4Я оставлю этот комментарий как предостережение для тех, кто без должной кадровой, технической и финансовой подготовки рванет в "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится". И не дочитав до конца, вообще решит избавиться от выделеных автоматизаторов.
Удобство написания тестов, как, например, при применении продвинутого фреймворка, конечно снижает, трудозатраты на создание и сценарную модификацию тестов. Но, есть принципиальная проблема, что, разработчики пишут плохой тестовый код. Не потому что не могут, а потому что по разным причинам не уделяют этому достаточно времени, и потому что привносят в тестовый код практики из продуктового программирования, что в автоматизации не всегда уместно.
Вот пример вчерашний.
Пришел на новый проект. Проекту 4 года , гибкая разработка, разработчики делают всё, и автоматизацию в том числе. Результаты тестов нестабильные. Причем если для селениума это еще можно как-то понять, то нестабильные интеграционные тесты - это уже серьезно. Так вот, стал копать селениум тесты. Выяснил, в частности, что некоторые функции имеющие в названии слово "check", на самом деле возвращают булево значение. А при применении функции не всегда обернуты в ассерт. И получается стал ковырять нестабильность, починил ее, а потом вышел на то, что тест-то ложно-негативный. Потому что булевы значения просто улетают в пустоту. И у нас бажина в программе, которую этот тест не чуял незнамо сколько уже времени.Потому что разработчик не может с той же въедливостью следить за тестовым кодом и его архитектурой как он может быть следит за продуктовым кодом. (Хотя, кого я обманываю там и продуктовый код тоже в таком же разболтаном состоянии). Отчасти это "эффект Простоквашино" - ...то лапы ломит, то хвост отваливается. Это когда над тестами работают все подряд, то, например, лепят кучу редундантных функций потому что разбираться в апи библиотеки функций нет времени.
А вот выделеный человек, он конечно чувствует свою полную ответственность, и понимает что удобно делает в первую очередь себе. И у него будет все по полочкам. И каждую функцию он будет знать по имени.
Но, конечно, любой автоматизатор, в конце концов, из всякой свалки бессвязного хлама, хочет сделать супермаркет. И вот тогда... в этом счастливом будущем, возможно разработчики будут просто набирать тесты, из готовых модулей (пусть это будут шаги featue-файла - не важно), а имплементацией этих модулей и их качеством будет заниматься автоматизатор.
Ну и что еще я заметил, это то что когда тестовый код пишут разработчики, то код тестов часто напоминает по стилю продуктовый код. А в автоматизации наоборот, хорошо иметь незамудреный код. Без выкрутасов. Потому что 60-80% времени автоматизатора уходит на поддержку тестов. Нужно быстро воспроизвести, зарепортить, или починить, не задев ничего другого, и бежать дальше.
Т.е. к тестовому коду разработчики относятся так, как будто этот код не будучи продуктовым заслуживает меньшего усердия. А на самом деле, тестовый код требует большего усердия. Если в продукте функционал работает и ладно, то в тестировании - тест зеленый и ладно - не ладно. Он может быть не по делу зеленый. И нужно пройти по нему, убедиться, что он не ложно-отрицательный и содержит только нужные проверки. И что, напротив, не содержит не относящихся к контексту тестового сценария проверок и шагов и так далее. Чтобы писать хороший тестовый код нужна дисциплина. А у разработчика психология другая. Они пытаются сэкономить силы, а это выливается в некачественные тесты.П.С.:
Я бы даже за сценариями следил, которые разработчики пишут, потому что некоторые считают, что слепить последовательность, которая описывает самую длинную цепочку действий, безотностительно к пользовательским сценариям - клевая идея. Ну или, если с фантазией похуже, то переключать чекбокс двадцать пять раз подряд - а вдруг отвалится.
generalitalics Автор
00.00.0000 00:00+1Тема довольно холиварная, но я с вами соглашусь — разработчики имеют другую психологию, нежели АТ и ФТ. Моя же команда состоит из людей, которые автоматизаторы, выросшие из кузни качества продукта. Поэтому и не было проблем в глубинном понимании всех болей тестирования, чтобы получился ортодоксальный продукт, прежде всего для ФТ. Мы разработчики лишь с той точки зрения, что пишем нормальный код и на 80% занимаемся кором. В дополнение мы собираем постоянную обратную связь, чтобы слушать и слышать наших ключевых пользователей — ФТ. Люди же, находящиеся на позиции классических разработчиков и которым дали сделать продукт автоматизации, часто срезают углы не от хорошей жизни, а лишь потому, что с них не снимают в это время продуктовую разработку.
Так как в нашей компании специалисты всех направлений имеют возможность писать автотесты на нашем продукте, то ревью итога все равно остается за ФТ. Они отвечают за качество продукта и за то как он оттестирован. Поэтому ситуации, что кто-то накидал длинную макаронину, которая что-то много того и не того проверяет — невозможна. У нас каждый автотест проверяет 100% тест-кейса.
Я искренне надеюсь, что те менеджеры, которые говорят "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится" имеют достаточно опыта в нашей индустрии, чтобы принять это решение взвешенно.
djglukbh
00.00.0000 00:00+1Могу сказать, что в данном случае организация АТ по сути исправляла ошибки по организации работ ФТ - не было общей базы и артефактория по тестам, не было координации работ по пониманию важности и возврата инвестиций от АТ к ФТ :)
Введение BDD - всегда дополнительный слой работ и всегда усложнение тестов. При наличии нормальной базы и наполнения беклога АТ я в реальности не видел чтобы это работало, ведь чтоб BDD взлетело - нужно чтобы ВСЕ писали и ВСЕ поддерживали - это титанический труд по контролю
Резюме: статья явно приукрашивает :) история хорошая - из разряда "мы сделали правильно в сложных условиях". но по сути - смысла реального в BDD не особо есть в случае нормальной работы ФТ/АТ. Тут явно ощущается некая продажа менеджменту его как серебряной пули :)
Как обычно в нашем ИТ - забиваем мелкие сапожные гвоздики кувалдой.
P.S. Статья не убеждает что это в реальности работает и помогает деливери.
generalitalics Автор
00.00.0000 00:00Очень рад, что вам понравилась моя история :)
Мы нескончаемо (как и все спецы качества в других компаниях) работаем над проработкой общей базы и артифактория по тестам. Понимание важности очень трудно показывать при смене классического метода подхода к структуре автоматизации — тут действительно были сложности, но сейчас уже есть все метрики, чтобы сказать, что такой подход для нас гораздо удачнее.
Работы над слоем BDD мы проделали в самом начале нашего пути переписывания кора. Сделали это основательно, чтобы не тратить на это время после. У нас теперь действительно все пишут и поддерживают. Это не умножение работы, а ее распределение, со снижением узкого горлышка AT и ФТ. Команда сама решает, кто будет писать автотесты в конкретный момент времени, а затем сама несет за них ответственность.
Ничего не преукрашивал, тут просто наш кейс с итогом, что взлетело. А BDD у нас идеально лег под вынос всех параметризированных шагов в webIDE и максимальному снижению планки входа в написание автотестов — без настроек и танцев с бубном.
Может, факт того, что наш ТТМ сократился на день за счет новых автотестов, убедит вас в том, что и с деливери у нас всё ок )
djglukbh
00.00.0000 00:00Ну собственно я ж написал про приукрашивание со стороны. А вообще - любой рассказ всегда остаётся рассказом без метрик, поэтому я акцентировал внимание, что статья не убеждает. Чиселки-то где? :)
Сколько проектов не видел (а видел много) - BDD только вносит проблемы. Хотя это и удобная штука для выноса написания самих тестов "вширь" из отдела АТ, я б не сказал, ИМХО, что это в реальности помогает с написанием тестов по их качеству. Количественно - возможно...
Gavi
00.00.0000 00:00+1И в очередной раз вместо нормального стека тестеры берут старый никому ненужный rest assured, да и вместо нормального тестового фреймворка junit 5, был взят testng. И ещё, вы на полном серьёзе используете чистый селениум?
generalitalics Автор
00.00.0000 00:00Как же rest assured может быть никому не нужен, если все его используют для API-автотестов. Вот, например, можно взять https://mvnrepository.com/tags/rest — он там номер 1. Библиотека существует уже больше 7 лет с постоянными обновлениями и пишется в очень приятной флюентинтерфейсной манере — чистый кайф.
Выбор junit 5 и testng окончательно стал лишь вкусовщиной, так как они оба отличные фреймворки с идентичными возможностями. Мое личное предпочтение — TestNG.
По селениуму согласен, что есть Selenide и другие обертки, начинающиеся на Selen..., но для нас это лишь крошечный слой, не влияющий на скорость выполнения автотестов. Основной движок UI-автотестов у нас на Atlas.
egribanov
00.00.0000 00:00Какие по вашему мнению есть альтернативы rest assured? Он развивается, уже работает в связке со спринг. Да и junit это основа тестирования на java, testng просто добавляет работу с тестовыми данными более удобную. Селенид хороший, но тянет слишком много лишних зависимостей, легче написать свою обертку над чистым селениумом. Есть playwright, тоже интересный, не требует установки браузера и можно вебкит тестировать, но у него свои особенности
max_shoshin
00.00.0000 00:00И вот как теперь жить? Мой тезка (по имени и фамилии) топит за Геркин... А я - активно топлю против...
Несколько сумбурно поясню свою позицию:
Мы пытаемся хороший код на хорошем языке программирования заменить очень урезанным языком описания тест кейсов (Gerkin).
Основная фишка данного подхода - «любая домохозяйка может написать тест». Проблема в том, что «домохозяйки» тесты не пишут - обычно пишут тесты все-равно разработчики или тестировщики.
А им удобнее пользоваться полнофункциональным языком программирования.Хороший фреймворк для тестов требует довольно аккуратной поддержки со стороны разработчиков.
Я видел ситуации когда BDD тесты превращались в огромную плохо поддерживаемую портянку. По которой невозможно навигироваться с помощью IDE, рефакторить их тоже нет никакой возможности.Часто разработчики, которые делают фичу делают что-то маленькое для поддержки в тестах и те кто вынужден писать автоматизированные тесткейсы - пишут их и мучаются, т.к. они не в состоянии поменять инфраструктуру (ну или цикл изменения этой инфраструктуры довольно длинный - проще написать как есть).
Мой путь - писать тесты разработчиками. Они пишут тесты на их языке программирования. Причем все возможности современных IDE им помогают. Если что-то больно (неудобно) писать - сам разработчик мучается и это именно тот человек который может что-то с этим сделать.
Да, на разработку фич требуется больше времени разработчиков. Но, как мне кажется, на длительном промежутке времени оно может окупаться.
Касательно Gerkin тестов - они наверное могут быть, но не надо их ставить во главу угла. Это инструмент, у которого есть плюсы и минусы. Нужно аккуратно думать прежде чем внедрять его.
generalitalics Автор
00.00.0000 00:00Прошу понять, что я не топлю за геркин, это лишь средство достижения цели. А цель была именно дать возможность писать тесты главным людям, имеющим знания ожидаемого поведения всей системы. Тест-кейсы не всегда показывают всю глубину необходимых проверок, поэтому автоматизаторы или разработчики, которые пишут автотесты по ним, часто сужают проверку, нежели ручные тестировщики, тем самым снижая качество продукта. Плюс добавляется игра в сломанный телефон с аналитиками про то, а как должно было быть. Поэтому мы и выпилили автоматизаторов из процесса написания автотестов и дали им заниматься фреймом.
Мое мнение, что если вы хотите дать своим продуктовым разработчикам ещё и автотесты писать, то для этого должны быть максимальные условия с точки зрения документации, тест-кейсов и процессов. Плюс давать проверять тому же человеку, что и изобрел что-то — это антипаттерн тестирования. Ведь все мы, как известно, не видим в своем глазу бревна.
TSergey_tm
00.00.0000 00:00+2Кому писать авто тесты - может быть вопросом узкого звена в цепи разработки.
У нас это тестировщики. И поэтому автотесты пишут разработчики.
Но фраза про то, что писать автотесты на свой код плохо, натолкнула меня на мысль, то автотесты к функционалу, реализованного одним разработчиком, должен писать другой. Это ещё будет способствовать узнаванию функционала.
Спасибо за идею.
McStar
00.00.0000 00:00А у меня простой вопрос. Как выглядит, например, какой-нибудь post запрос на геркире, чтобы можно было понять какой json он засылает?
generalitalics Автор
00.00.0000 00:00Вот пример, как это сделано у нас:
Тут 2 параметра: эндпоинт и тип рестового метода. А в DataTable заполнение ключ-значение json. По-умолчанию все, кроме true/false, является типом String. Если нужно что-то другое, то можно воспользоваться в value допками, типа "Integer:". При запуске запрос виден полностью с урлом, хедерами и json в привычном виде:
McStar
00.00.0000 00:00Ну это плоский json, такие редко бывают. А если вложенность? Или списки? Ну, например:
```json
{
"field1": 2,
"field2: {
"field21": "value21",
"field22": "value22"
},
"list": [
{
"list1": "listvalue"1
}
]
}
```
ну и так далее.
generalitalics Автор
00.00.0000 00:00Вложенность у нас делается через точку, а списки так и остаются, так как у нас бывают редко:
Но если вы отправляете очень объемные рестовые запросы, то не стоит, как мне кажется, их засовывать в геркин полностью, а то это сильно ударит по читаемости автотестов. Советую использовать что-то типа FreeMarker'а для создания запросов-шаблонов, в которых большая часть значений будет статична(и только изменяемая часть станет тем самым DataTable), а ссылаться в самом шаге на шаблон по его названию *.json. Мы так сделали для мокирования, так как там нужно ставить заглушку на ответ, который почти всегда объемный.
McStar
00.00.0000 00:00Понятно. Похоже на TOML чем-то. Ну, так себе. :)) А почему не через Docstring тогда?
generalitalics Автор
00.00.0000 00:00Я встречал TOML только в инвентарниках Ansible. По мне не похоже )
По Docstring не понял, как его тут можно применить, но с удовольствием бы послушал ваши мысли по этому поводу, хоть у нас и Java, а не Python.McStar
00.00.0000 00:00Не понял причём тут python? Я имел в виду это https://cucumber.io/docs/gherkin/reference/ тут поиском docstrings. В таком случае можно писать json как есть без всяких табличных извращений. :)
generalitalics Автор
00.00.0000 00:00А, понял про что речь теперь. Да, вещь хорошая, но размер такого шага увеличится процентов на 20 из-за переносов и скобок. Читаемость в минимальное число экранов снизится, что влияет на быстрый анализ автотеста глазами. Для нас DataTable хороший и лаконичный формат, который себя хорошо зарекомендовал и исправно работает.
J_uliet_ta
00.00.0000 00:00Прям сморю и слезы на глаза наворачиваются. Бэк-энд тесты можно писать во время разработки, с большоц скоростью, например, на Java+JUnit5+restAssured(или Spring Boot). А с этим огурцом, надо сохранять промежуточные результаты, рефакторить жутко не удобно и тд. Никогда не используйте Cukumber для бэка. Совет от автоматизатора с опытом 8 лет и видавшим кучу проектов. В автотестиррование пришла не из "ручников", образование айтишное.
generalitalics Автор
00.00.0000 00:00Стек для бэкенда у вас выбран отличный, сам такой бы выбрал, но заменил бы JUnit5 на TestNG. Более того движок серверных тестов у нас на этом же стеке, если снова посмотреть на текст статьи. Cucumber у нас лишь для того, чтобы написание автотестов было удобно вынести в браузер - через webIDE. Так получается, что сервер - это не единственная платформа, требующая автоматизации у нас, а есть еще 2 мобильные платформы и веб. Таким образом наш проект позволяет в едином пространстве писать 4 вида автотестов без всяких настроек. Если вы занимаетесь только автоматизацией бэкенда, то можно и обойтись фреймами, работающими только с кодом. Для этого я и написал финальную часть "Не повторяйте это дома, трюк выполнен подготовленными специалистами" - где я призываю все хорошенько обдумать, ведь моя статья не руководство к действию, а кейс.
McStar
00.00.0000 00:00А чем testNG лучше Junit5? Особенно с учётом того, что TestNG не шибко активно развивается.
generalitalics Автор
00.00.0000 00:00Я начинал писать на TestNG в 2016м. Тогда был JUnit4, который не только уступал в функциональности, но и уже 2 года, к тому времени, не выпускал обновления. А сейчас они оба имеют аналогичные возможности, оба развиваются и стали лишь делом вкуса и привычки. Более того JUnit5 себя отлично зарекомендовал и теперь является тоже отличным выбором.
azzas
Ни разу не видел чтобы после танцев с Cucumber'ом тесты писал кто то кроме разрабов-автоматизаторов. Этот лишний уровень только путает и нормально не дает видеть что конкретно происходит в тесте.
generalitalics Автор
Да, я раньше к cucumber'у тоже скептически относился. Но потом мы как раз использовали этот самый "лишний уровень" и все его преимущества для выноса на веб-платформу и написания там автотестов любым it-спецом. Все получилось и работает хорошо. Скорость написания и поддержки увеличились в разы.
jsel333
И как "любые it-спецы"? Пишут автотесты? Очень часто просто есть требование для BDD прослойки от менеджмента, просто потому что, а пользоваться им никто так и не начинает, и по итогу core команда автоматизации поддерживает и свой фреймворк, и весь BDD уровень, и так же обычно это просто рудимент, на который тратится очень много времени, на поддержку, а "застрелить не поднялась рука"
generalitalics Автор
Ага, пишут достаточно активно. Поначалу было сложно вводить это в продуктовые команды из-за естественного сопротивления, но сейчас уже всё ок. Основные пользователи продукта автоматизации это аналитики и ручные тестировщики — те it-спецы, которые точно знают, как должно быть правильно на проверках. BDD-уровень мы не поддерживаем — там уже нами разработаны все необходимые виды шагов для воплощения любого существующего сценария. Мы пилим и улучшаем кор, а сами автотесты в руках команд.
iBljad
Ну как раз в очень больших организациях с недостатком квалифицированных (в плане разработки автотестов) специалистов такая история и может работать: узкий круг специалистов сделал конструктор, остальные "кликают мышкой", например, Альфа несколько лет назад хвалилась успехом своей Акиты на огурце.
Вызывает вопрос другое: зачем до этого автоматизаторы "сами для себя" писали на геркине? Чтобы что?.. (или это как раз были выпускники "диагональных" курсов, которые просто пользовались тем, чем умели?)
generalitalics Автор
Раньше у нас был другой тип использования автоматизаторов — гибридный. Это когда люди находятся в продуктовых командах, пишут автотесты этой команды и еще тестируют руками новый функционал. У нас этот вариант совсем не взлетел, так как все ресурсы уходили на ручное тестирование, а автоматизация была по остаточному принципу. Потом с автоматизаторов сняли ручное тестирование, чтобы число автотестов увеличилось, но и это, в команде, работающей над быстрорастущим приложенем с редизайнами, давало КПД близкий к 0. Потом сели, подумали и сделали вот такой продукт, который уже отлично себя зарекомендовал.
Это я к тому, что, когда только внедрялся огурец, было совсем не до аккуратного выстраивания BDD. Поэтому это был булшит, который логировал методы и давал их чуть переиспользовать с выплывающем подсказом от cucumber. Не я внедрял, но зато работа с ним помогла допустить вариант с текущим решением.