нужно построить только корректный XPath, проверить его в браузере

Только дженкинс локально надо поднимать на своем основном сетевом интерфейсе, а не локалхосте. Ну или nginx прикрутить чтобы проксировал на локалхост запросы извне

Как проверить его?

ввести в Ctrl+F в консоли разраба на вкладке исходного кода страницы, нажать Enter

Только если в хроме

Спасибо, попробую

Спс, завтра попробую

что-то типа

//div[@class="ScrollbarsCustom-Content"]/span[1]

Class обычно лучше на contains искать, если через xpath

если несколько классов, то не словит без контейна?

Да, если вдруг че-нить добавят, то не рабочий станет

//div[@data-testid='UIKIT.CustomSkroll']/span

или

//div[contains(@data-testid='CustomSkroll')]/span

By.class еще можно, он тоже на вхождение смотрит но сплитает по пробелам

Привет. Может кто-то объяснить принцип page element. По сути это страница на которой описываются методы которые помогают взаимодействовать с определенными элементами на странице которые повторяются?

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

Просто единственный пример который я нашел это работа с таблицей  там реально нужно описать прям взаимодействие с таблицей и это типо можно назвать page element. Может кто-то может подсказать какие ещё варианты имплементации могут быть?

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

Точняк! Вот и я говорю, что “пэдж обжект” совершенно ничем не отличается от просто объекта. Это жа самое обычное ООП, а не какой-то там паттерн.

P.S. Вот здесь накидано несколько вариантов пэдж обжекта: https://github.com/selenide-examples/google/tree/master/test/org/selenide/examples/google

Не совсем понимаю что будет внутри кастомного элемента для данной ситуации. Ну то есть какие методы там будут? Только верификация того что есть валидация? Или ещё что-то? И то есть под каждый такой элемент будет создаваться класс? Как много их может быть?

Современные ui фреймворки основываются на компонентном подходе, когда есть библиотека переиспользуемых компонентов и из этих компонентов собираются страницы (https://reactjs.org/docs/design-principles.html#composition). Логично, что в таком случае в тестовом фреймворке пейдж обжекты можно декомпозировать на пейдж элементы, которые соответствуют компонентам тестируемого приложения для того, чтобы получить тот же самый профит этого подхода в тестах - переиспользование, single responsibility, etc.