А-а-а-а)). Автор вопроса - не я ))

🙄

Вот оригинал😄

Я для поиска по тексту использую xpath.  До идеи через css селекторы тоже можно.  Такой селектор можно сразу проверить в Chrome что елемент находится.  Селектор будет иметь такой вид:
//*[contains(text(),'Замовник')]

Искать по тексту это бэдстайл - вам нужен уникальный атрибут, типа неизменяемого ID.

Я переписав все на селектори через класи, посилання на текст чогось е працює, ні звичайне ні часткове ні через селектор

Я не помню как работает поиск по ссылке под капотом, но подозреваю, что там просто берутся все ссылки <a на странице и уже по ним ищется текст.

Проверьте как у вас задана эта кнопка и думаю стоит поменять локатор на id или class.

Спасибо, уже переписал через селекторы и забил)
Дальше буду на пайтон обджект пернписывать

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

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

>но текст не надо никогда использовать
не слишком ли категорично? Не надо забывать, что все зависит от проекта. И всегда есть сценарии, когда текст останется без изменений, а остальное поедет. И наоборот. Вопрос только в том, как быстро можно починить тест.

Текст важен с точки зрения пользователя. Если испортится текст - тест должен упасть

вы не о том спорите) Речь вроде шла о том, что нельзя использовать текст в качестве селектора. А валидировать текст очень даже надо. А если поехала вся разметка после обновления, то надо конечно и тесты переделывать

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

Иногда проще не искать элемент, а потом в нем текст, а сразу икспасом искать по тексту). Если проект моноязычен -это работает.

О том и речь — многое зависит от проекта. Эти "нельзя" очень странно звучат. Где-то селекторы по тексту отлично себя покажут, где-то нет. Не на каждом проекте есть возможность прописать свои персональные айдишники, которые, кстати, не дают гарантии, что они случайно не повторятся где-то дважды на странице из-за невнимательности или плохого знания проекта. Собственно, как выше написали — селекторы с текстом хорошо могут работать для одного языка. Но если человек будет тратить кучу времени на поиск идеального css или xpath (и так каждый раз после обновления), то от этого мало пользы. Все же надо с умом подходить.

+1. Есть в тестах места где лучше работает именно текст

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

у Игоря, похоже, как-то не получается в лидогенерацию при поиске сотрудников

Хочу чтоб было описание WebElement чтоб потом можно было распечать его хорошо бы чтоб ассерт печатал его, есть такое может где готовое что типа:

@Description("Amount input")
@FindBy(id = "amountInput")
WebElement fieldAmount;

хорошая идея