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

xpath
locators
css-selectors
webdriver
Теги: #<Tag:0x00007fedbc1322c8> #<Tag:0x00007fedbc132188> #<Tag:0x00007fedbc131ff8> #<Tag:0x00007fedbc131eb8>

(Dmitry Nesterov) #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


(Nikita) #4

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

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


(Vladislav Kulasov) #5

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


(Прокопук Дмитрий) #6

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

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

(Lev Yarushin) #7

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


(Прокопук Дмитрий) #8

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


(Lev Yarushin) #9

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


http://elementalselenium.com/tips/32-xpath-vs-css
http://elementalselenium.com/tips/33-xpath-vs-css-revisited


(Алексей Смиян) #10

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


(Lev Yarushin) #11

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


(Yury) #12

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

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

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

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


(Vladislav Kulasov) #13

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


(Sergey Pirogov) #14

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


(Ray Romanov) #15

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


(Sergey Pirogov) #16

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


(Yaroslav Pernerovskyy) #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.

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

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


(Ramis Vakazov) #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 + '")]'));

(Yaroslav Pernerovskyy) #19

При том, что есть (по крайней мере были раньше) браузеры, которые не умеют (не умели) в икспас, и с такими браузерами селениум работал через свою собственную прослойку. (http://www.seleniumhq.org/docs/03_webdriver.jsp#by-xpath)

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

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

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

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

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

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


(Maxim Andryushchenkov) #20

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


(Dmitry Bezzubikov) #21
  1. предпочитаю xpath именно по причине лёгкости их построения и восприятия вследствии логичности подхода к описанию по иерархии элементов и соседей в отличие от условных символов
  2. xpath построенный любым автоматизированным средством как правило не имеет никакого смысла ибо представляет собой сплошные индексы. их надо грамотно и осознанно писать
  3. насчёт скорости работы css по сравнению с xpath. Ну это практически легенда не основанная ни на чём. Хотя довольно популярная.
  4. Ни в коем случае не умаляю достоинств локаторов css и готов их применять если это будет целесообразно. На самом деле самое главное что есть выбор. Не вижу никакого смысла в противопоставлении одного другому без объективных причин.