testomat.io управление авто тестамиПредпочитаю вообще ими не пользоваться если возможно, а уж тем более через firebug, который дает absolute xpath, а не relevant. Мой приоритет таков: by ID, by Name, by CSS и на худой конец xpath.
А если посмотреть на эти локаторы, то они очень похожи и принципы построения в них одинаковы.
.//*[@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
Я стараюсь использовать поиск по тексту, в этом как раз помогает xpath.
Т.е большую часть времени, я даже не открываю вёрстку сайта:
$(byText(“text”)).click();
2 лайка
Потому что xpath более понятен и более гибок. Кроме firepath есть другие плагины.
1 лайк
не соглашусь с вами, что xpath более понятен.
В большинстве случаев css намного лаконичнее, понятнее и короче, чем xpath
- к этому css быстрее
Xpath - это сразу делался как язык запросов к элементам XML-документа. А CSS вообще для стилей был сделан изначально, не нужно об этом забывать. Есть вещи которые CSS не умеет делать ( например ось preceding-sibling в Xpath), и наоборот (например Element:focus или :checked)
Используйте что удобнее и проще.
2 лайка
согласен. Да я вообще редко видел, чтобы в автоматизации псевдоклассы использовали, хотя штука очень полезная. Но я думаю, что большинство забыло суть xpath и css + к этому css оказывается “сложный”
Я наверное не так незвал тему и боль свою немного по-другому назвать надо было: “Ищите локаторы сами!”
Ещё добавлю.
То что XPath медленнее CSS мягко говоря не так )
4 лайка
В firepath можно не только копировать xpath, но и прописывать его вручную с проверкой корректности и количества найденных с таким xpath-ом элементов. Очень удобно.
1 лайк
В современных браузерах это можно сделать проще.
В консоли - $x(“XPath”)
$$(“CSS”)
2 лайка
Вопрос скорее должен звучать - появился бы вообще Firepath, если бы не XPath?
А вообще эту тему тут разжевывали однажды: CSS vs XPath - кто сильнее? - #16 от пользователя polusok
Вроде как сошлись, что это вопрос личного предпочтения.
К слову в Ranorex (туле для тестирования десктопных приложений) поиск объектов осуществляется с помощью XPath. То есть сфера его применения выходит далеко за пределы веба.
1 лайк
[quote] В большинстве случаев css намного лаконичнее, понятнее и короче [/quote] Ну не сказал бы, вот Brainfuck — Википедия еще лаконичнее и короче и примерно также понятнее. 
По скорости уже ответили, это заблуждение гуляет еще с селениум1.
Шота вы лепите слепого и горбатого. Где статистика что Xpath популярнее?
Статистика по моим автотестам xPath более 70% случаев, т.к. частенько приходится двигаться назад, что не позволяет CSS
Ну так, то что тебе нравиться или получается писать только Xpath, не значит что в индустрии так пишут все 
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 лайков
Вообще говоря, при чем здесь нативнее для браузера 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 лайк
При том, что есть (по крайней мере были раньше) браузеры, которые не умеют (не умели) в икспас, и с такими браузерами селениум работал через свою собственную прослойку. (The Selenium Browser Automation Project | Selenium)
CSS же, с самого начала проекта селениум, поддерживался в браузерах и селениум опирался и опирается на нативную реализацию поиска, которая реализована в браузере, а не в драйвере (раньше были ньюансы с совсем древними ИЕ и ФФ и там был sizzle, но теперь это в прошлом)
Это про нативное.
Про дом - стратегия поиска с использованием CSS селекторов это тоже навигация по дом дереву, просто синтаксис другой и возможности победнее, но зато лаконично. Просто сравните:
form.user.name
и
//form[contains(@class,’user’) and contains(@class,name’)]
.table
и
//*[@class='table']
Все же надо уметь применять и то и другое, главное осознанно.
1 лайк
Пользуюсь только xpath потому что в текст локатора через xpath можно вложить кусочек логики. А грамотные xpath пути чтобы тесты не ломались - вообще наука
2 лайка
- предпочитаю xpath именно по причине лёгкости их построения и восприятия вследствии логичности подхода к описанию по иерархии элементов и соседей в отличие от условных символов
- xpath построенный любым автоматизированным средством как правило не имеет никакого смысла ибо представляет собой сплошные индексы. их надо грамотно и осознанно писать
- насчёт скорости работы css по сравнению с xpath. Ну это практически легенда не основанная ни на чём. Хотя довольно популярная.
- Ни в коем случае не умаляю достоинств локаторов css и готов их применять если это будет целесообразно. На самом деле самое главное что есть выбор. Не вижу никакого смысла в противопоставлении одного другому без объективных причин.
2 лайка