Да, у меня так вышло, что сейчас я работаю одновременно с Selenium и PW (Selenium для desktop-приложения и PW для веба). Если брать что-то из очевидного, то:
скорость
удобство разработки (если брать чистый селениум, то это чаще неудобно, приходится дописывать свою логику, яркий пример -- ожидания с логированием)
возможности из коробки (т.е. киллер-фичи фреймворков, в PW их больше, потому что продукт свежий достаточно и у него нет легаси, которое нужно поддерживать)
оркестрация драйверами браузеров в CI у PW происходит через вебсокеты, это быстрее и стабильнее
Но это не значит, что Selenium плохой. Он очень хорош в разных ситуациях, например, основные фреймворки для тестирования мобилок (не берём нативные) -- selenium-based, десктоп - тоже selenium-based, очень много информации и большая экспертиза. Нужно смотреть обособленно на выбор фреймворка. Поэтому сейчас использую оба подхода каждый день.
(конечно, матерюсь с селениумом как сапожник, но главное, что работает и делает то, что должен делать)
Ну, не всегда прям должно быть всё равно какой язык/стек/фреймворк использовать. Если есть совпадение по одному из признаков со стеком компании, то да, уже легче выбрать фреймворк, к примеру. Но полностью ресёрчи я бы не выкидывал. Если делается с запасом на будущее, то лучше это продумать заранее, шифт-лефт, все дела)
В целом, хороший вариант, но опции PW немного ограничены, если такой формат не отпугивает, то why not. У меня такая же ситуация, только с питоном на данный момент
Я могу ошибаться, но вроде даже создатели пупитира и делают PW сейчас (Andrey Lushnikov и Joel Einbinder). Инструмент хороший, не спорю, но не рассмотрел его, потому что нечасто сталкивался с этой связкой лично. Не спорю, что она имеет место быть сейчас наравне с другими инструментами. Спасибо, будет, что потестировать в свободное время :)
Спасибо :) В автоматизации есть 2 важных этапа: научиться искать локаторы и применять их в сценариях. Есть отличная практика. Заходим на любой сайт, например, DNS, Epic games и т.д. Придумываем тест-кейс, например: 1. Открыть страницу 2. Ввести в поле поиска название товара 3. Нажать на название товара 4. Убедиться, что отображается кнопка Купить
После этого понимаем, что нам нужно найти локаторы поля поиска, товара, кнопки Купить. Комбинируем варианты с CSS (если локатор простой), если нужно завязаться на текст, то тогда с помощью XPath. В общем, удачи! Если будут вопросы, то обращайтесь в ЛС ;)
Полностью согласен, только это тема относится к массивам локаторов, которые не были рассмотрены в данной статье. Будет отличным поводом написать мини-дополнение с разбором сложных и неординарных кейсов типа такого, когда для определенной бизнес-задачи необходимо находить больше одного локатора
В автоматизации работаю уже 5 лет, был на разных проектах, на всех одинаково плевались на XPath за счёт его громоздкости :) Говорю не только своё мнение, а исходя из опыта своего и других ребят. В статье не было умысла убедить не использовать XPath, лишь рассмотреть, когда он реально может пригодиться, если с помощью CSS никак.
ох, фреймы и шэдоурут -- это такая боль, знаю не понаслышке)) с массивами чекбоксов для инерактивного взаимодействия -- отличное замечание, наверное, надо будет потом написать мини-дополнение к статье со сложными кейсами, типа таких (+шэдоурут и фреймы)
Основные плюсы (продублирую часть таблицы) -- он простой, краткий, человекопонятный и его +- знают больше, чем XPath. Также я понимаю, что не везде можно применить CSS, поэтому смело можно и нужно использовать XPath.
Раньше сталкивался с массивами локаторов, но понял, что проще найти один уникальный с помощью XPath (если не получается с помощью CSS), всегда найдется что-то, за что можно зацепиться. Но да, согласен, массивы локаторов можно обрабатывать, но на практике встречал пару-тройку раз в виде исключения, поэтому не рассматривал этот подход в статье
А про XPath не знал, если это так, то звучит логично на самом деле ?
Делается очень просто, почти во всей фреймворках есть метод, который достаёт локатор по тексту в элементе, например, в Protractor (как писал выше в коментах): element(by.cssContainingText(element, text)). Можно и с помощью xpath: //*[contains(text(), "текст")]. Надеюсь, я правильно понял вопрос
Полностью согласен с замечанием, что сопоставлять *= и точку -- нельзя, но это было сделано для наглядности. Мол, локатор можно записать и так, и так, а именно: .btn или [class*="btn"] (с оговоркой, что предпочтительнее использовать сокращенную форму)
Да, в этом тоже есть смысл, но я больше про русский текст в атрибутах. Например, тот же Protractor позволяет искать по тексту в локаторе с помощью element(by.cssContainingText(element, text)), в таких случаях без русского никуда :)
Классная статья, часто сталкиваюсь с подобным сам и вижу, как сталкиваются с этим другие на этапе обучения чему-то новому. Чаще всего проблема заключается в том, что человек складывает лапки и "помогите, я не знаю", даже не попытавшись подумать, почитать, осознать причину появления ошибки, я молчу уже про то, что иногда полезно смотреть на стэктрейс :)
Да, у меня так вышло, что сейчас я работаю одновременно с Selenium и PW (Selenium для desktop-приложения и PW для веба). Если брать что-то из очевидного, то:
скорость
удобство разработки (если брать чистый селениум, то это чаще неудобно, приходится дописывать свою логику, яркий пример -- ожидания с логированием)
возможности из коробки (т.е. киллер-фичи фреймворков, в PW их больше, потому что продукт свежий достаточно и у него нет легаси, которое нужно поддерживать)
оркестрация драйверами браузеров в CI у PW происходит через вебсокеты, это быстрее и стабильнее
Но это не значит, что Selenium плохой. Он очень хорош в разных ситуациях, например, основные фреймворки для тестирования мобилок (не берём нативные) -- selenium-based, десктоп - тоже selenium-based, очень много информации и большая экспертиза. Нужно смотреть обособленно на выбор фреймворка. Поэтому сейчас использую оба подхода каждый день.
(конечно, матерюсь с селениумом как сапожник, но главное, что работает и делает то, что должен делать)
Ну, не всегда прям должно быть всё равно какой язык/стек/фреймворк использовать. Если есть совпадение по одному из признаков со стеком компании, то да, уже легче выбрать фреймворк, к примеру. Но полностью ресёрчи я бы не выкидывал. Если делается с запасом на будущее, то лучше это продумать заранее, шифт-лефт, все дела)
В целом, хороший вариант, но опции PW немного ограничены, если такой формат не отпугивает, то why not. У меня такая же ситуация, только с питоном на данный момент
Про "апишку", кажется, нужно писать отдельный пост, там тоже свои инструменты классные есть :)
Я могу ошибаться, но вроде даже создатели пупитира и делают PW сейчас (Andrey Lushnikov и Joel Einbinder). Инструмент хороший, не спорю, но не рассмотрел его, потому что нечасто сталкивался с этой связкой лично. Не спорю, что она имеет место быть сейчас наравне с другими инструментами. Спасибо, будет, что потестировать в свободное время :)
Прекрасно знаком, потому что одно время работал SDET и совмещаю работу SDET и менеджера прямо сейчас ;)
Хорошая статья, спасибо!
А можно немного подробнее? Речь о флаге --wm-window-animations-disabled и подобных или я неправильно понял?
Спасибо :) В автоматизации есть 2 важных этапа: научиться искать локаторы и применять их в сценариях. Есть отличная практика. Заходим на любой сайт, например, DNS, Epic games и т.д. Придумываем тест-кейс, например:
1. Открыть страницу
2. Ввести в поле поиска название товара
3. Нажать на название товара
4. Убедиться, что отображается кнопка Купить
После этого понимаем, что нам нужно найти локаторы поля поиска, товара, кнопки Купить. Комбинируем варианты с CSS (если локатор простой), если нужно завязаться на текст, то тогда с помощью XPath. В общем, удачи! Если будут вопросы, то обращайтесь в ЛС ;)
Не :) Protractor + Jasmine + TS, гоняется это всё на селеноиде (локально поднимаю с помощью webdriver-manager хромдрайвер)
Спасибо ?
Полностью согласен, только это тема относится к массивам локаторов, которые не были рассмотрены в данной статье. Будет отличным поводом написать мини-дополнение с разбором сложных и неординарных кейсов типа такого, когда для определенной бизнес-задачи необходимо находить больше одного локатора
В автоматизации работаю уже 5 лет, был на разных проектах, на всех одинаково плевались на XPath за счёт его громоздкости :) Говорю не только своё мнение, а исходя из опыта своего и других ребят. В статье не было умысла убедить не использовать XPath, лишь рассмотреть, когда он реально может пригодиться, если с помощью CSS никак.
ох, фреймы и шэдоурут -- это такая боль, знаю не понаслышке)) с массивами чекбоксов для инерактивного взаимодействия -- отличное замечание, наверное, надо будет потом написать мини-дополнение к статье со сложными кейсами, типа таких (+шэдоурут и фреймы)
Основные плюсы (продублирую часть таблицы) -- он простой, краткий, человекопонятный и его +- знают больше, чем XPath. Также я понимаю, что не везде можно применить CSS, поэтому смело можно и нужно использовать XPath.
Раньше сталкивался с массивами локаторов, но понял, что проще найти один уникальный с помощью XPath (если не получается с помощью CSS), всегда найдется что-то, за что можно зацепиться. Но да, согласен, массивы локаторов можно обрабатывать, но на практике встречал пару-тройку раз в виде исключения, поэтому не рассматривал этот подход в статье
А про XPath не знал, если это так, то звучит логично на самом деле ?
Делается очень просто, почти во всей фреймворках есть метод, который достаёт локатор по тексту в элементе, например, в Protractor (как писал выше в коментах): element(by.cssContainingText(element, text)). Можно и с помощью xpath: //*[contains(text(), "текст")]. Надеюсь, я правильно понял вопрос
Полностью согласен с замечанием, что сопоставлять *= и точку -- нельзя, но это было сделано для наглядности. Мол, локатор можно записать и так, и так, а именно: .btn или [class*="btn"] (с оговоркой, что предпочтительнее использовать сокращенную форму)
Да, в этом тоже есть смысл, но я больше про русский текст в атрибутах. Например, тот же Protractor позволяет искать по тексту в локаторе с помощью element(by.cssContainingText(element, text)), в таких случаях без русского никуда :)
Но замечание огонь! ?
Полностью согласен, надёжные атрибуты -- наше всё :)
Классная статья, часто сталкиваюсь с подобным сам и вижу, как сталкиваются с этим другие на этапе обучения чему-то новому. Чаще всего проблема заключается в том, что человек складывает лапки и "помогите, я не знаю", даже не попытавшись подумать, почитать, осознать причину появления ошибки, я молчу уже про то, что иногда полезно смотреть на стэктрейс :)