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()
И этого вполне достаточно для обеспечения выразительности кода, как мне кажется))
Надеюсь смог ответить на все вопросы.
Да, все тесты встроены в pipeline, но в отличие от unit-тестов, они не являются блокирующими. После прохождения тестов, формируется подробный allure-отчет по которому любой инженер QA, даже не автоматизатор может с легкостью определить причину падения и в дополнение идет отправка уведомления в корп. мессенджер, где подсвечивается общее число тестов, число успешных и упавших тестов. Соответсвенно, если в этом сообщении все тесты успешно прошли, то смотреть отчет не требуется. Если есть упавшие, то любой из свободных инженеров (не дежурный на регрессе) идет смотреть отчет. Дальше уже по ситуации. Если поменялся функционал, а тесты не поменялись, то требуется их доработать и это идет отдельной тех.долговой задачей. Тут к сожалению на ручном приводе. В остальных случаях падения отталкиваемся уже от ситуации. Может быть проблема с инфрой. В этом случае тест можно повторно запустить вручную и убедиться, что проблема уже устранена(особенно, если жалоб с регресса не поступало). Если проблема с функционалом, то заливается фикс, после чего история с автозапуском в пайпе повторяется.
Что касается распараллеливания - тут используются встроенные средства junit, ничего кастомного нет, но важно понимать это при создании архитектуры проекта и писать код, который не будет конфликтовать в многопоточном исполнении и придерживаться атомарности каждого теста. Нельзя использовать общие тестовые данные. Для каждого теста свои тестовые данные с созданием и удалением после теста.
Конкретно e2e тесты запускаются асинхронно только в рамках тестирования на разных движках, т.к. в настоящий момент не прошли критическую точку по общему времени их выполнения. Возможно в будущем потребуется это проработать, но проблем не должно быть, т.к., как написал выше архитектурно это уже заложено.
Добрый день. Точно делать. Описывайте там приобретенный профессиональный опыт во время выполнения финальной работы и, возможно, процессные вещи, которые имеют ценность (например, вам удалось поучаствовать в командной разработке с другими ребятами с курсов или принимать участие в проработке стратегии тестирования, если говорить о QA). Да, там не будет изобилия решаемых вами производственных задач, но при правильной подаче (без скатывания в тривиальные вещи) это положительно выделит вас на фоне других кандидатов без опыта. В целом, если у вас нет опыта, то скорее всего:
Вы молодой выпускник учебного заведения (не обязательно профильного). Тогда в принципе для вас это норма, т. к. все мы с чего-то начинали. Есть ряд организаций, которые осознанно берут молодых ребят, чтобы обучить их под себя. Наличие хорошо структурированного резюме без пробелов является конкурентным преимуществом и как минимум показывает, что вы способны подсветить свои сильные стороны и показать свой опыт.
Вы человек, который решил сменить сферу своей деятельности, и тут может быть два варианта:
У вас технический бэкграунд, но вам по какой-то причине стало плохо на текущем месте/позиции. Ну вот, бывает такое, что человек в какой-то момент понимает, что это не его, и кардинально меняет свою жизнь, откатываясь назад. Это достаточно выгодная позиция — наличие технического бэкграунда, пусть и не профильного, в совокупности с уже какими-то полученными профильными знаниями сильно выделяет на фоне остальных. И это обязательно нужно подсветить. И вот тут как раз многие пренебрегают тем, чтобы описать этот новый опыт по-хорошему. Кто-то считает, что его нельзя показывать на равных с предыдущим своим опытом, и заталкивают куда-нибудь в далекий уголок. Кто-то описывает достаточно скудно, не тратя на это особых усилий, кто-то перечисляет учебную программу. Однако если вы опишите этот опыт с практической стороны (как я писал в начале комментария), то это будет огромным плюсом.
У вас нет технического бэкграунда. Да, это самая невыгодная позиция, но это еще ничего не значит. Описывайте приобретенный на курсах практический опыт, и снова повторюсь: вы выделитесь на фоне других кандидатов без опыта, которые этого не сделали по-хорошему. Да, возможно (я прям подчеркиваю, что возможно), вы не попадете в какой-нибудь биг/финтех, но есть огромное количество других организаций, которым нужны рабочие руки и которые готовы обучить базовым вещам. Ну а дальше все уже будет зависеть от вас. Дерзайте!
Добрый день.
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() И этого вполне достаточно для обеспечения выразительности кода, как мне кажется)) Надеюсь смог ответить на все вопросы.
Да, все тесты встроены в pipeline, но в отличие от unit-тестов, они не являются блокирующими. После прохождения тестов, формируется подробный allure-отчет по которому любой инженер QA, даже не автоматизатор может с легкостью определить причину падения и в дополнение идет отправка уведомления в корп. мессенджер, где подсвечивается общее число тестов, число успешных и упавших тестов. Соответсвенно, если в этом сообщении все тесты успешно прошли, то смотреть отчет не требуется. Если есть упавшие, то любой из свободных инженеров (не дежурный на регрессе) идет смотреть отчет. Дальше уже по ситуации. Если поменялся функционал, а тесты не поменялись, то требуется их доработать и это идет отдельной тех.долговой задачей. Тут к сожалению на ручном приводе. В остальных случаях падения отталкиваемся уже от ситуации. Может быть проблема с инфрой. В этом случае тест можно повторно запустить вручную и убедиться, что проблема уже устранена(особенно, если жалоб с регресса не поступало). Если проблема с функционалом, то заливается фикс, после чего история с автозапуском в пайпе повторяется.
Что касается распараллеливания - тут используются встроенные средства junit, ничего кастомного нет, но важно понимать это при создании архитектуры проекта и писать код, который не будет конфликтовать в многопоточном исполнении и придерживаться атомарности каждого теста. Нельзя использовать общие тестовые данные. Для каждого теста свои тестовые данные с созданием и удалением после теста.
Конкретно e2e тесты запускаются асинхронно только в рамках тестирования на разных движках, т.к. в настоящий момент не прошли критическую точку по общему времени их выполнения. Возможно в будущем потребуется это проработать, но проблем не должно быть, т.к., как написал выше архитектурно это уже заложено.
Добрый день. Точно делать. Описывайте там приобретенный профессиональный опыт во время выполнения финальной работы и, возможно, процессные вещи, которые имеют ценность (например, вам удалось поучаствовать в командной разработке с другими ребятами с курсов или принимать участие в проработке стратегии тестирования, если говорить о QA). Да, там не будет изобилия решаемых вами производственных задач, но при правильной подаче (без скатывания в тривиальные вещи) это положительно выделит вас на фоне других кандидатов без опыта. В целом, если у вас нет опыта, то скорее всего:
Вы молодой выпускник учебного заведения (не обязательно профильного). Тогда в принципе для вас это норма, т. к. все мы с чего-то начинали. Есть ряд организаций, которые осознанно берут молодых ребят, чтобы обучить их под себя. Наличие хорошо структурированного резюме без пробелов является конкурентным преимуществом и как минимум показывает, что вы способны подсветить свои сильные стороны и показать свой опыт.
Вы человек, который решил сменить сферу своей деятельности, и тут может быть два варианта:
У вас технический бэкграунд, но вам по какой-то причине стало плохо на текущем месте/позиции. Ну вот, бывает такое, что человек в какой-то момент понимает, что это не его, и кардинально меняет свою жизнь, откатываясь назад. Это достаточно выгодная позиция — наличие технического бэкграунда, пусть и не профильного, в совокупности с уже какими-то полученными профильными знаниями сильно выделяет на фоне остальных. И это обязательно нужно подсветить. И вот тут как раз многие пренебрегают тем, чтобы описать этот новый опыт по-хорошему. Кто-то считает, что его нельзя показывать на равных с предыдущим своим опытом, и заталкивают куда-нибудь в далекий уголок. Кто-то описывает достаточно скудно, не тратя на это особых усилий, кто-то перечисляет учебную программу. Однако если вы опишите этот опыт с практической стороны (как я писал в начале комментария), то это будет огромным плюсом.
У вас нет технического бэкграунда. Да, это самая невыгодная позиция, но это еще ничего не значит. Описывайте приобретенный на курсах практический опыт, и снова повторюсь: вы выделитесь на фоне других кандидатов без опыта, которые этого не сделали по-хорошему. Да, возможно (я прям подчеркиваю, что возможно), вы не попадете в какой-нибудь биг/финтех, но есть огромное количество других организаций, которым нужны рабочие руки и которые готовы обучить базовым вещам. Ну а дальше все уже будет зависеть от вас. Дерзайте!
Спасибо за совет! Не хотел особо акцентироваться на себе, но на будущее учту. Меня зовут Станислав, я тимлид одной из продуктовых команд в Здравсити)