Комментарии 21
А матчить по рэгэкспу этот ваш xpath может?
А нет ли вероятности,что небольшая переверстка тестируемой страницы при использовании XPath приведет у падению теста? И переделке автотестов?
В этом плане как раз name, id или кастомные идентификаторы элементов спасут от лишних хлопот.
Обычно не влияет, в xpath есть "//" и "/" если вёрстка меняется настолько, что xpath становится не верным, то и css так же поломается, id конечно нужны, но по ним можно искать и используя xpath, а вот поиск по тексту - это удобно для тестов
Тут автор же не запрещает их пользовать - пользуйте наздоровье, XPath это умеет, просто имейте в виду ту самую, возможную переверстку... Когда фронтэндер может поменять id или name, а вот текст ему менять просто нельзя.
Привязаться к id или name - абсолютно нормальная практика IMHO, когда это применимо.
Привязаться к id или name — абсолютно нормальная практика IMHO, когда это применимо.
Ну на самом деле лучше сразу готовиться к тому, что текст может тоже меняться, особенно если у вас многоязычное приложение. Наиболее частое решение этой проблемы — это добавление Test ID к необходимым элементам. Если получается договориться с разработчиками, конечно.
Большая часть примеров по поиск по тексту. На деле конечно эту проблему можно легко решать через js, но видимо для тестов подкручивать js им не охота.
К сожалению не увидел ни простых описаний XPath, примеры не так легко читаются как кажется автору. Ни крутых примеров, где они элегантно и кратко делают что-то, что через js сделать сложнее.
В целом XPath нужный и прикольный инструмент, но не для html. Как-то пилил себе на планшет приложение-интерфейс для одного пиратского сайта, и в виду java и не желания тратить ресурсы крайне старого планшета на web-view (цель как раз была избавиться от оного) пришлось пользоваться XPath. К сожалению то что пишется на нем быстро и без изучения выглядит отвратительно, но в целом применение оного к html и предполагало что все будет плохо.
Ну и да, цеплять что-то за текст на сайте такая себе идея. Видимо вам прокатывает. У себя я бы бил по рукам. И заставил бы добавлять в режиме дебага селекторы, в стиле в сессии debug_selectors = on, и на все что только потребуются добавляются классы в стиле debug_some_name. А то добавится у вас на проект мультиязычность и придется копировать все тесты, плюс если это будет какой-нибудь китайский, то прочитать этот селектор будет уже невозможно.
ПС. планшет был настолько старым, что для проверки авторизован ли я, пришлось отказаться от поиска через XPath, взять первые 10000 символов и пройтись регуляркой. Получилось в разы быстрее.
В общем хотел бы вставить не колько коммкнтов к статье из личного опыта:
Xpath медленее чем css и это видно при большом обращении к поиску элементов в доме. Конечно возможно 3 селениум где-то кэширует большое количество запросов к дому по одному и тому же селектору, но это вряд ли. Медленее потому что xpath рекурсивно обходит дом в отличии от css selector и тут можно холиварить сколько угодно об оптимизации алгоритмов обхода и построения деревьев, но все равно прямая ссылка вниз быстрее чем рекурсивный обход. Кстати поэтому продвинутые инструменты типа сайпреса не поддерживают xpath из коробки)))))
Эти примеры хороши, но на практике фронты используют что-то типа бэм. И тут можео селектор вещать на блок, элемент или модификатор. И если у вас новый элемент в блоке, то упадет и xpath. А повесив на модификатор селектор, можно например фиксировать эти модификаторы на элементах.
К тексту можно привязываться и к всяким атрибутам только в случае, если вы используете xpath как шаблон, который потом параметризируется, а гнать туда статические данные смысла нет от слова совсем. Конечно если у вас не висит стандартная и голая таблица без модификаторов, что в реале вряд ли. Если же вы используете xpath в инициализации полей того же пейджа, то лучше css.
Если у вас фронт не использует бэм или другие best practice, гоните такой фронт в шею. )))) У вас жопа с сапортом кода будет и переиспользованием компонентов и блоков.
Использовать функции хорошо, но ими не нужно злоупотреблять, опять же скорость при большом количестве обращений, а если еще и джава, то плюс время на запуск jvm))))
Ну и как написали выше ребята, развитие xpath под сомнением.
И если свойства таких элементов могут измениться, то текст чаще всего останется прежним.
Текст как минимум меняется взависимости от языка и при использовании интерполяции строк. Не говоря уж о том, что он может просто менятся без изменения логики работы. Лучше задавать каждому элементу уникальный идентификатор, который не будет меняться при редизайне и правке текстов. Подробнее я рассказывал про этот подход в статье Фрактал имён элементов.
//select[@name=’field[new_object_assignment_key]’]/..//a
Тут вы очень жёстко завязались на вёрстку. Добавит разработчик доп обёртку и всё, приехали. Корректный селектор с поиском по оси предков или со вложенными xpath запросами будет уже куда менее лаконичным.
Разработчики зачастую добавляют свои атрибуты ко множеству тегов. Через CSS и стандартными методами фреймворков тестирования их не найти.
Ну приехали. CSS так-то имеет даже целую коллекцию удобных модификаторов для поиска текста в атрибутах, которых очень не хватает в XPath. Вообще, очень печально, что развитие XPath остановилось вместо того, чтобы объединить лучшие качества CSS и Xpath.
Вообще, очень печально, что развитие XPath остановилось вместо того, чтобы объединить лучшие качества CSS и Xpath.
Ну строго говоря — развитие самого XPath не остановилось, просто в браузерах используют только версию 1.0 от 99-го года, а версии 2.0(2010) и 3.0(2014), ну и разрабатываемый 4.0 — видимо не будут имплементированы в браузерах никогда.
Наверняка в вашем случае, описанный подход оптимален. Но если есть возможность, то, как мне кажется, лучше придерживаться подхода "The more your tests resemble the way your software is used, the more confidence they can give you". Автор этого эмпирического правила набросал небольшую статью на тему, которая задает хороший майндсет.
Использовать xPath нужно только там, где без него не обойтись, например поиск по тексту )) Во всех оставшихся случаях CSS лаконичнее и гораздо понятнее. От исключительного использования xPath уже в глазах рябит.
Зачем писать так: //div[contains(@class,'bold') and contains(@class,'nowrap') and contains(@class,'menu-a')]
Если можно: div.bold.nowrap.menu-a
Не ограничивайте себя )
Зачем писать так: div.bold.nowrap.menu-a
Если можно: //[@my_menu_item]
Не пишите ерунды)
Интересно где в каком месте div.bold.nowrap.menu-a находиться my_menu_item ?
Не пишите ерунды)
Используйте инструменты, которые позволяют не писать ерунды, тогда у вас не будет никаких div.bold.nowrap.menu-a в принципе.
Вот почему мы всегда пишем селекторы на XPath