привет всем! можете подсказать а можно как-то использовать такой XPath: id("content")/div[1]/header[1]/div[2]/div[1]/div[4]/div[1]/div[1]/div[2]/a[1] ??

можно использовать. Но это больно потом читать и понимать и править

тем более очередность элементом может поменяться

id нету, и класов по названию похожих много

id нету, и класов по названию похожих много

надо верстку смотреть, так никто не скажет хороший локатор или нет

лучше по id или class элемент выбирать

А чем лучше-то?

А чем лучше-то?

тем более очередность элементом может поменяться

и уже div[2], к примеру, не проканает

Очередность элементов - это изменение в верстке. С таким же успехом локатор может поменяться на другой. Любые изменения в верстке могут сломать локатор, факт.

id нету, и класов по названию похожих много

я в таких случаях делал несколько составляющих типа class + текст

вообще искать каждый раз в глобальном контексте - нестабильно как по мне

не знаю, как другие

зато данный локатор будет почти железно находить только 1 элемент

я обычно нахожу блоки, а потом уже ищу внутри них

а, ну да. Я понял. Спасибо?

я обычно нахожу блоки, а потом уже ищу внутри них

аналогично

я обычно нахожу блоки, а потом уже ищу внутри них

А в чем глобальная разница, если поиск блока у вас всё равно проходится по всему дому?

типа - let loginForm = $('.loginform') await loginForm.$('.username').sendKeys(user) await loginForm.$('.password').sendKeys(password)

А в чем глобальная разница, если поиск блока у вас всё равно проходится по всему дому?

ну тут прикол в том как сами верстальщики верстают, они обычно тоже обявляют блоки, компонеты всякие

удобно находить такие инкапсулированные блоки которые в верстке существуют

я даже как то выступал с этой идеей. Это абсолютно не новая идея, странно что в автотестировании ее так мало используют

https://www.youtube.com/watch?v=aSmTwARoPJA&list=PLEUkJQfJdxsTg4al8YrSVp4BxC4ds9biH&index=6

Ну, это скорее про организацию локаторов и структуру кода проекта, на мой взгляд, нежели про подход к поиску элементов. Но, возможно я чего-то не понимаю.

Ну, это скорее про организацию локаторов и структуру кода проекта, на мой взгляд, нежели про подход к поиску элементов. Но, возможно я чего-то не понимаю.

а оно все связано в итоге

Нет, не связано. :)

Ну, т.е. связанность зависит от того, как вы это реализовываете.

Нет, не связано. :)

очень даже, локаторы в этом подходе получаются очень короткими, и поддерживать проще

очень даже, локаторы в этом подходе получаются очень короткими, и поддерживать проще

Чем хороши короткие? И почему короткие локаторы поддерживать проще?

У тебя в итоге всё равно получается конкатенация локаторов (локатор блока + локатор элемента). Я не вижу особого плюса в "коротких" локаторах, т.к. они всё равно скрыты под неймингом. Вероятность изменения оного меняется только тогда, когда у вас часто перетаскивают по структуре страницы целые блоки UI.

Это довольно ситуативный кейс, я бы сказал.

Чем хороши короткие? И почему короткие локаторы поддерживать проще?

дебажить же проще. В длинном локаторе долго искать что конкретно поменялось

У тебя в итоге всё равно получается конкатенация локаторов (локатор блока + локатор элемента). Я не вижу особого плюса в "коротких" локаторах, т.к. они всё равно скрыты под неймингом. Вероятность изменения оного меняется только тогда, когда у вас часто перетаскивают по структуре страницы целые блоки UI.

конкатенация выполняется на уровне вебдрайвер API, я не клею ничего через +

конкатенация выполняется на уровне вебдрайвер API, я не клею ничего через +

Да какая разница на каком уровне она выполняется, если принцип работы остается тем же?

и там тоже не через + а через указание контекста

Вы что там, что сям оперируете абсолютными путями.

Да какая разница на каком уровне она выполняется, если принцип работы остается тем же?

нет, это уже особенности контекста в вебдрайвер, и нас они не волнуют

Относительные пути имеют обратное свойство - при некорректном контексте конкатенация может выдать валидный элемент, который не является целью тестирования.

нет, это уже особенности контекста в вебдрайвер, и нас они не волнуют

Ну, если вас не волнуют - хорошо вам. :)

дебажить же проще. В длинном локаторе долго искать что конкретно поменялось

У тебя не найден либо блок либо элемент. при длинных не найден элемент. и в том и том случае тебе лезть в браузер и смотреть куда же он уехал

У тебя не найден либо блок либо элемент. при длинных не найден элемент. и в том и том случае тебе лезть в браузер и смотреть куда же он уехал

блок это и есть элемент.

У тебя не найден либо блок либо элемент. при длинных не найден элемент. и в том и том случае тебе лезть в браузер и смотреть куда же он уехал

в этом то и мякотка, в подарок получаешь типизацию элементов

блок это и есть элемент.

Неужели

твой - MyNiceElement == WebElement

да, я для этого и написал библиотеку на js

но впринципе ее можно легко реализовать и на java, те же HTMLelements работают в этом же направлении

В общем, подход, конечно, вполне жизнеспособен, но рекомендовать его как silver bullet - довольно спорное решение, потому что реальных плюсов оно ... может и не давать вообще. А вот лишний геморрой при дебаггинге может добавлять.

но мне не нравится использовать анотации, я за ленивые элементы

И все ради "пути короткие и красивенькие".

Столько проблем с автоматами, что радеть за дебаг при смене путей бессмысленно имхо

В общем, подход, конечно, вполне жизнеспособен, но рекомендовать его как silver bullet - довольно спорное решение, потому что реальных плюсов оно ... может и не давать вообще. А вот лишний геморрой при дебаггинге может добавлять.

В любом подходе есть плюсы и минусы. В этом подходе мы работаем больше в ООП стиле, инкапсуляция здесь очень хорошая

И все ради "пути короткие и красивенькие".

дело не в том что короткие и красивенькие, а то что простые локаторы проще дебажить. Вопрос как дебажить - это уже легко решить на уровне биндингов. Те же джавашные биндинги автоматом сохраняют всю цепочку локаторов которая использовалась для поиска конкретного какого-то глубокого элемента

В любом подходе есть плюсы и минусы. В этом подходе мы работаем больше в ООП стиле, инкапсуляция здесь очень хорошая

Возникает только один вопрос: зачем?

Возникает только один вопрос: зачем?

Я же целую лекцию записал специально :)

Возникает только один вопрос: зачем?

чтобы ответить на вопрос зачем

дело не в том что короткие и красивенькие, а то что простые локаторы проще дебажить. Вопрос как дебажить - это уже легко решить на уровне биндингов. Те же джавашные биндинги автоматом сохраняют всю цепочку локаторов которая использовалась для поиска конкретного какого-то глубокого элемента

Я так и не увидел аргументов, почему короткие пути проще дебажить, кроме как "проще найти какая часть xpath изменилась", как будто вы вручную два xpath сравниваете.

Я так и не увидел аргументов, почему короткие пути проще дебажить, кроме как "проще найти какая часть xpath изменилась", как будто вы вручную два xpath сравниваете.

потому что вы работаете в конкретном контексте, а не по всей странице. Если у вас в компоненте что-то изменилось, вам не нужно дебажить локатор по всей странице, а достаточно ограничить поиск конкретным компонентом

потому что вы работаете в конкретном контексте, а не по всей странице. Если у вас в компоненте что-то изменилось, вам не нужно дебажить локатор по всей странице, а достаточно ограничить поиск конкретным компонентом

А если у вас лежит длинный локатор то вы, надо полагать, понятия не имеете в каком блоке данный локатор используется, и будете перебирать методом свободного поиска все элементы страницы, пока не найдете нужный?

А если у вас лежит длинный локатор то вы, надо полагать, понятия не имеете в каком блоке данный локатор используется, и будете перебирать методом свободного поиска все элементы страницы, пока не найдете нужный?

А зачем вы выносите локаторы отдельно из компоненты?

Я ни откуда их не выношу, я точно так же могу их структурировать по компонентам, используя при этом абсолютные пути, вместо скрытого под капотом контекста.

Я ни откуда их не выношу, я точно так же могу их структурировать по компонентам, используя при этом абсолютные пути, вместо скрытого под капотом контекста.

а как же переиспользование компонент на разных страницах?

Вот, это уже больше похоже на аргумент.

Вот, это уже больше похоже на аргумент.

вообще мне нравится ход ваших мыслей

Вот, это уже больше похоже на аргумент.

вот тут больше примеров кода, правда на TypeScript - я был бы благодарен за фидбек в личку - https://github.com/Xotabu4/protractor-element-extend

Здесь зависит от: если мы гарантируем, что поведение компонента на всех страницах идентично независимо от контекста (что может быть совсем не так), то данный подход может принести реальные плоды. Но, на мой взгляд, проще использовать id в таких случаях, чем добавлять в тесты контекст, который нужно всегда учитывать.

Здесь зависит от: если мы гарантируем, что поведение компонента на всех страницах идентично независимо от контекста (что может быть совсем не так), то данный подход может принести реальные плоды. Но, на мой взгляд, проще использовать id в таких случаях, чем добавлять в тесты контекст, который нужно всегда учитывать.

бывает да, компоненты по разному работают на разных страницах. Тут нужно понимать есть ли общее, что мы можем вынести. Тогда я бы наследовал типа - class Checkbox extends WebElement {} class SomeExtraLogicCheckbox extends Checkbox {}

Я бы предпочел независимую от локаторов логику вынести в отдельные классы, а локаторы заменить на id, вместо xpath.

Но, на вкус и цвет, вероятно.

Я бы предпочел независимую от локаторов логику вынести в отдельные классы, а локаторы заменить на id, вместо xpath.

Конечно, лучше иметь айдишники которые не меняются.

Вы так говорите, как будто это требует каких-то нечеловеческих усилий, несоизмеримых с обработкой контекста в тестах. :)

Вы так говорите, как будто это требует каких-то нечеловеческих усилий, несоизмеримых с обработкой контекста в тестах. :)

Иногда это требует согласование и 4 подписи.

Иногда это требует согласование и 4 подписи.

Тогда самое время отвлечься от автотестов и заняться QA, что бы сделать систему пригодной для тестирования.

Я бы предпочел независимую от локаторов логику вынести в отдельные классы, а локаторы заменить на id, вместо xpath.

Я увидел этот подход очень крутым когда работал с чем то по типу страницы результатов. У меня есть class SearchResults<SearchResult> extends BaseArrayFragment {} и я могу делать прекрасные вещи - new SearchResults().getResultWithLowestPrice().openDetails()

Тогда самое время отвлечься от автотестов и заняться QA, что бы сделать систему пригодной для тестирования.

Ага. И тебе, разумеется, дали на это права.

.getResultWithLowestPrice() Возвращает мне уже типизированный елемент SearchResult - у которого уже есть метод - откройся

Ага. И тебе, разумеется, дали на это права.

Это сильно зависит от того, на какую работы вы устраивались. У меня таких проблем обычно не возникало.

Везет вам.

Везет вам.

Причем тут везение-то? Если одна из ваших должностных обязанностей - отлаживать QA процессы, то права на это у вас есть by default.

А если не обязанность?

Или "да, конечно. надо 4 подписи и согласовывать все".

Кстати такой подход с некоторыми переименованиями еще и очень понятен фронтендерам, потому что они делают структуру своего фронтенд кода очень похоже. Можно даже переиспользовать те же имена классов что они дают в своем коде.

Тогда вы сами выбрали работу, в которой не контролируете рабочие условия. Остается только страдать.

Кстати такой подход с некоторыми переименованиями еще и очень понятен фронтендерам, потому что они делают структуру своего фронтенд кода очень похоже. Можно даже переиспользовать те же имена классов что они дают в своем коде.

А ещё можно генерить "HTMLElements" для автотестов на основе кода приложения

А ещё можно генерить "HTMLElements" для автотестов на основе кода приложения

потенциально. Но всеравно прийдется методы писать самому )

А ещё можно генерить "HTMLElements" для автотестов на основе кода приложения

хотя может некоторые методы можно и генерить... я думал про это, но нет времени занятся вплотную

Ребята, привет! А есть среди вас те, кто занимались нагрузочным тестированием?))

какой бестактный вопрос -)

хотя может некоторые методы можно и генерить... я думал про это, но нет времени занятся вплотную

Но тут нужен тогда порядок кода хороший. На выходе иметь типизированные контролы

Ребята, привет! А есть среди вас те, кто занимались нагрузочным тестированием?))

лучше конткретику. тут любят такое

Но тут нужен тогда порядок кода хороший. На выходе иметь типизированные контролы

не хочешь помочь мне? У меня есть пару идей на этот счет. Могу в личку обьяснить

Прошу прощения за бестактность) но я ищу тех, кто работал с HP LoadRunner и с JMeter, разрабатывали нагрузочные скрипты и т.п.

Прошу прощения за бестактность) но я ищу тех, кто работал с HP LoadRunner и с JMeter, разрабатывали нагрузочные скрипты и т.п.

Елена, вопрос-то какой?) Есть ли люди такие? Да, есть. Вас устроит такой ответ?) Или же нужно что-то более конкретное?)

Если есть, то это ж замечательно) а кто-нибудь работу ищет из нагрузочников??

яснопонятно

Если есть, то это ж замечательно) а кто-нибудь работу ищет из нагрузочников??

там спросите: @qa_jobs - незабудьте прочесть припиненное сообщение, а то опять зафлудят...

Спасибо)

Всем привет! Ребята, как при помощи WebDriver сбросить кэш в браузере?

Всем привет! Ребята, как при помощи WebDriver сбросить кэш в браузере?

стартаните новую сессию

Всем привет! Ребята, как при помощи WebDriver сбросить кэш в браузере?

driver.delete_all_cookies()

driver = webdriver

Угу, спасибо, счас буду пробовать!)