Был бы ли так распространен xpath без firepath?

webdriver
, , ,
#1

Размышлял над темой: почему в UI автоматизации один из самых популярных локаторов #xpath . И понял, что все зло кроется в firepath. Все, кто делает первые шаги в автоматизации начинают с firepath, часто бездумно просто копируют локаторы.

А вы спрашивали у frontend разработчиков, что они предпочитают. Я думаю большинство из них ответит #css и query селекторы рулят, а если вы скажите #xpath , то с удивлением на вас посмотрят.
Если не привязываться к браузеру(#firefox ), забыть про тулы, был бы настолько популярен xpath?

1 лайк
#2

Предпочитаю вообще ими не пользоваться если возможно, а уж тем более через firebug, который дает absolute xpath, а не relevant. Мой приоритет таков: by ID, by Name, by CSS и на худой конец xpath.

#3

А если посмотреть на эти локаторы, то они очень похожи и принципы построения в них одинаковы.
.//*[@ng-repeat=“item in $ctrl.tiles”][1]/div/ul/li[1] - xpath
‘[ng-repeat=“item in $ctrl.tiles”]:first-child>div>ul>li:first-child’ - css

#4

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

$(byText(“text”)).click();

2 лайка
#5

Потому что xpath более понятен и более гибок. Кроме firepath есть другие плагины.

1 лайк
#6

не соглашусь с вами, что xpath более понятен.
В большинстве случаев css намного лаконичнее, понятнее и короче, чем xpath

  • к этому css быстрее
#7

Xpath - это сразу делался как язык запросов к элементам XML-документа. А CSS вообще для стилей был сделан изначально, не нужно об этом забывать. Есть вещи которые CSS не умеет делать ( например ось preceding-sibling в Xpath), и наоборот (например Element:focus или :checked)
Используйте что удобнее и проще.

2 лайка
#8

согласен. Да я вообще редко видел, чтобы в автоматизации псевдоклассы использовали, хотя штука очень полезная. Но я думаю, что большинство забыло суть xpath и css + к этому css оказывается “сложный”
Я наверное не так незвал тему и боль свою немного по-другому назвать надо было: “Ищите локаторы сами!”

#9

Ещё добавлю.
То что XPath медленнее CSS мягко говоря не так )

4 лайка
#10

В firepath можно не только копировать xpath, но и прописывать его вручную с проверкой корректности и количества найденных с таким xpath-ом элементов. Очень удобно.

1 лайк
#11

В современных браузерах это можно сделать проще.
В консоли - $x(“XPath”)
$$(“CSS”)

2 лайка
#12

Вопрос скорее должен звучать - появился бы вообще Firepath, если бы не XPath?

А вообще эту тему тут разжевывали однажды: CSS vs XPath - кто сильнее? - #16 от пользователя polusok

Вроде как сошлись, что это вопрос личного предпочтения.

К слову в Ranorex (туле для тестирования десктопных приложений) поиск объектов осуществляется с помощью XPath. То есть сфера его применения выходит далеко за пределы веба.

1 лайк
#13

[quote] В большинстве случаев css намного лаконичнее, понятнее и короче [/quote] Ну не сказал бы, вот Brainfuck — Википедия еще лаконичнее и короче и примерно также понятнее. :slight_smile:
По скорости уже ответили, это заблуждение гуляет еще с селениум1.

#14

Шота вы лепите слепого и горбатого. Где статистика что Xpath популярнее?

#15

Статистика по моим автотестам xPath более 70% случаев, т.к. частенько приходится двигаться назад, что не позволяет CSS

#16

Ну так, то что тебе нравиться или получается писать только Xpath, не значит что в индустрии так пишут все :wink:

#17

xPath распространен сам по-себе, без всякого firepath’a, но в чем-то есть доля правды, особенно для самоучек, которые пока не осознали, что выбор локатора определяется контекстом автоматизации.

Зрелые же автоматизаторы выбирают, то что уместно в конкретном случае.

Если это браузер, то лучше использовать то, что нативно для браузера. Для браузера CSS роднее (BTW, by_id, by_name, by_class_name это тоже CSS локаторы, просто обернутые для удобства). Потому CSS, в силу своей лаконичности, понятности для фронтендщиков и нативной поддержки во всех браузерах, предпочтительный и рекомендуемый вариант. Исключение, это описание работы с табличками, и всякими перечислениями, и необходимость бегать взад вперед по ДОМу, тут XPath без вариантов, потому что индексы и axes.

C другой стороны, xpath более универсален, так как специально был разработан для навигации по разного рода древовидным структурам. Например если у нас не браузер а, скажем appium с каким то iOS девайсом на конце, то описать локатор элемента через xpath мы сможем, а вот css там обломается в большинстве случаев.

За универсальность приходится платить скоростью, в том же Appium xpath работает всегда но дико медленно, и лучше использовать нативную стратегию поиска для iOS или Android.

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

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

11 лайков
#18

Вообще говоря, при чем здесь нативнее для браузера css? xpath создан для работы с xml и html представляет собой структуру xml. И работаю я с домом, потому удобнее находить именно в доме. Тем же самым xpath-ом можно построить аналогичные css, id, class-name локаторы. Все унифицировано и понятно.

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

На проекте с генерируемыми классами, не договорились с разработчиками о добавлении id-шников, только xpath-ом мог строить для себя такие конструкции:

var changeNewVodType = (type) => element(by.xpath('//h4[contains(.,"...текст...")]//following-sibling::div//span[contains(.,"' + type + '")]'));
1 лайк
#19

При том, что есть (по крайней мере были раньше) браузеры, которые не умеют (не умели) в икспас, и с такими браузерами селениум работал через свою собственную прослойку. (The Selenium Browser Automation Project | Selenium)

CSS же, с самого начала проекта селениум, поддерживался в браузерах и селениум опирался и опирается на нативную реализацию поиска, которая реализована в браузере, а не в драйвере (раньше были ньюансы с совсем древними ИЕ и ФФ и там был sizzle, но теперь это в прошлом)

Это про нативное.

Про дом - стратегия поиска с использованием CSS селекторов это тоже навигация по дом дереву, просто синтаксис другой и возможности победнее, но зато лаконично. Просто сравните:

form.user.name
и
//form[contains(@class,’user’) and contains(@class,name’)]

.table
и
//*[@class='table']

Все же надо уметь применять и то и другое, главное осознанно.

1 лайк
#20

Пользуюсь только xpath потому что в текст локатора через xpath можно вложить кусочек логики. А грамотные xpath пути чтобы тесты не ломались - вообще наука

2 лайка