Comments 5
У вас е2е тесты встроены в pipeline? Если да, то какие тесты запускаются синхронно, какие асинхронно? Если тест падает, потому что функциональность обновилась, то кто его правит? Как на это планируется время?
Вот это и подобное было бы суперинтересно...
Да, все тесты встроены в pipeline, но в отличие от unit-тестов, они не являются блокирующими. После прохождения тестов, формируется подробный allure-отчет по которому любой инженер QA, даже не автоматизатор может с легкостью определить причину падения и в дополнение идет отправка уведомления в корп. мессенджер, где подсвечивается общее число тестов, число успешных и упавших тестов. Соответсвенно, если в этом сообщении все тесты успешно прошли, то смотреть отчет не требуется. Если есть упавшие, то любой из свободных инженеров (не дежурный на регрессе) идет смотреть отчет. Дальше уже по ситуации. Если поменялся функционал, а тесты не поменялись, то требуется их доработать и это идет отдельной тех.долговой задачей. Тут к сожалению на ручном приводе. В остальных случаях падения отталкиваемся уже от ситуации. Может быть проблема с инфрой. В этом случае тест можно повторно запустить вручную и убедиться, что проблема уже устранена(особенно, если жалоб с регресса не поступало). Если проблема с функционалом, то заливается фикс, после чего история с автозапуском в пайпе повторяется.
Что касается распараллеливания - тут используются встроенные средства junit, ничего кастомного нет, но важно понимать это при создании архитектуры проекта и писать код, который не будет конфликтовать в многопоточном исполнении и придерживаться атомарности каждого теста. Нельзя использовать общие тестовые данные. Для каждого теста свои тестовые данные с созданием и удалением после теста.
Конкретно e2e тесты запускаются асинхронно только в рамках тестирования на разных движках, т.к. в настоящий момент не прошли критическую точку по общему времени их выполнения. Возможно в будущем потребуется это проработать, но проблем не должно быть, т.к., как написал выше архитектурно это уже заложено.
Как вы вовремя. Как раз за подобную задачу взялся и стек тот же. Было бы интересно осветить несколько доп моментов:
1) на сколько я знаю, есть практика сравнения сразу снимками экрана по эталону. Вы используете такое? Если да, то насколько это удобно/практично? Можно ли как-то отсечь какие-то динамические куски (скажем баннер крутится)?
2) Так же вроде можно DOM/HTML сравнивать. Насколько это рабочая тема? Или все тут же сломается из-за имен стилей и т.п.?
3) Хорошо бы всё же Allur тут видеть
4) DSL нам тут не поможет? Для меня Kotlin это конечно вот все что вы перечислили, но еще и выразительный DSL. А тут прям так руки и чешутся описывать структуру страницы через свой DSL что бы можно было писать типобезопасные тесты особенно в ситуации если блоки не имеют id/name/уникальных имен классов/стилей. Как к ним навигироваться? Ну и просто люди далекие от кода могли выражать тест примерно перенося картинку в текст теста.
Или структура сайта/страниц меняется чаще и поддерживать DSL в актуальном состоянии все замучаются?
Добрый день.
1. Да, сравнение по скриншотам вполне хорошая практика и playwright очень хорошо справляется с этим из коробки. Если нужно убрать какую-то часть, то можно использовать маски. При использовании маски вы можете передать локатор (css класс, id или любой другой атрибут) динамического элемента и он не будет включен в проверку. Однако стоит понимать, когда нужно использовать такие тесты и не включать их всегда и везде. Если у вас есть какие-то лендинги , какой-то визуальный контент, который достаточно критичен для пользователя и поехавшая верстка может нести существенный репутационный риск, то конечно такие тесты обязательны в общем скоупе. С другой стороны, если вы работаете с админкой или каким-то внутренним продуктом, где есть некоторая лояльность конечного пользователя, то таких тестов может быть не много или не быть совсем, т.к. главное, что бы элементы были видимы, кликабельны, активны и т.д., что можно проверить и без использования скриншот тестов. Я несколько подробно остановился на этом вопросе, потому что тесты со скриншотами подразумевают их подготовку, поддержку и не исключают флаки по магическим причинам, зависящим в том числе от фазы луны)
2. По поводу сравнения DOM, тут может быть много мнений, но конкретно мое - отрицательное. HTML и css очень непостоянная вещь в мире разработки и в динамично развивающемся продукте меняется очень часто (название классов, вложенность элементов, табличная верстка, а через месяц верстка на блоках и тд тп). Поэтому я бы такое не рекомендовал, но опять же, это связано с отсутствием у меня положительного опыта в этом.
3. С allure возможно дойдут руки и я напишу отдельную статью, где будет и это. Но если кратко, то в описанном подходе не требуется отдельной прослойки в виде степов. У нас есть публичные методы внутри блоков, которые взаимодействуют с компонентами и вот их можно и нужно помечать аннотацией @Step. В этом случае в отчете allure будет прозрачно видно какое действие и в какой последовательности вызывалось. В самих тестах мы расставляем аннотации @Epic, @Story, что позволяет категоризовать тесты.
4. Да, DSL безусловно мощный инструмент в котлине, которым грех не воспользоваться. И на одной из итераций я пошел этим путем, что бы можно было работать в стиле page { block { text {} input {} } } Но в какой-то момент поймал себя на мысли, что ухожу от главной задачи фрэймворка тестирования в создание движка по генерации страниц и решил от этого отказаться. В тестах я использую fluent синтаксис, например page .navigation() .content .getTitle() И этого вполне достаточно для обеспечения выразительности кода, как мне кажется)) Надеюсь смог ответить на все вопросы.
Автоматизируем тесты UI с помощью Kotlin (Playwright + JUnit5)