Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

CSS vs XPath - кто сильнее?


(sidelnikovmike) #1

Всем доброго времени суток.
Не так давно в одной из тем я задал вопрос - почему во многих примерах на форуме наши коллеги используют xpath? почему не css?
Ответа я сразу не получил, и очень хотелось бы услышать некоторые мысли по этому поводу.
В свою очередь я немного посидел и посмотрел на некоторые аспекты этих 2-х способов. Свои мысли изложил у себя здесь - http://sidelnikovmike.blogspot.ru/2013/11/selenium-css-xpath.html

Было бы интересно подискутировать. Разумеется, без холивара :smile:


Сборник полезных ссылок по локаторам
Скорость и нагрузка разных локаторов (какой лучше использовать)
Дайджест полезных ссылок для тестировщиков-автоматизаторов #010
(Дмитрий Жарий) #2

@sidelnikovmike на первый взгляд, очень интересное исследование.
Почитаю вечерком.

А пока, могу предложить добавить ссылку на ваш пост в АвтоХомяк

Могу еще предложить добавить блог в “трансляцию блогов” на software-testing.ru
Как, описано тут . Так, вы сможете привлечь больше читателей.


(Сергей Блохин) #3

Не всегда есть id, class и т. д.
Порой единственный способ найти элемент — это его xpath.
Чтобы не плодить сущности я всегда использую xpath.

p. s.: УРАААА!!! Добавили автоперевод строки в комментариях!


(sidelnikovmike) #4

Спасибо!
Насчет “хомяка” - я только за!
Насчет трансляции - вдвойне спасибо! Доберусь до компьютера - обязательно сделаю.


(sidelnikovmike) #5

Да, разумеется.
А ре могли бы вы привести какой-нибудь пример? Из достаточно часто используемых? Было бы интересно.


(Сергей Блохин) #6

Например, ссылка со случайным текстом внутри.

<a href="messages">%count% new messages</a>

Порой такой элемент можно найти только через XPath, т. к. метод поиска по тексту не подходит, атрибуты id и class у элемента отсутствует.


(Mykhailo Poliarush) #7

Итого для explorer: вот тут сильно разнятся, причем проигрывает CSS. Чуть ли не в 2 раза. Если честно - я не ожидал.

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

Но я в своей практике, также очень часто использую xpath (когда нет id), потому что он мне дает все необходимые возможности достать элементы, независимо от того, есть там какие-то аттрибуты или нет.


(sidelnikovmike) #8

Да, меня explorer тоже удивил. Я не раз проверил, но результат именно такой получился


(Александр Таранков) #9

Мне тут подумалось насчет того, почему CSS-локаторы рекомендуют. Возможно потому, что UI-разработчики именно их используют для поиска элементов через JS, следовательно, и для
автотестов они подойдут. А по наглядности CSS-локатор более краткий получается.

Хотя, я использую только XPath-локаторы. Просто по-привычке. А так же по причине, которую уже озвучил @TIT - для единообразия


(rmerkushin) #10

xpath вроде лучше поддерживается таким старьем как IE6. По работе приходилось автоматизировать под него на QTP, и в IE6 не всегда работали CSS селекторы, пришлось от них полностью отказаться.


(sidelnikovmike) #11

@joemast согласен про использование и краткость. Но всегда ли краткость - это хорошо?
Я бы сказал, что css просто популярнее. Во многом из за jquery, как мне кажется.
@rmerkushin - ага , я тоже слышал, что в некоторых версиях IE проблемы с поддержкой CSS.


(Mykhailo Poliarush) #12

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


(sidelnikovmike) #13

краткость, как мне кажется, не есть оптимальность. Вы скорее про второе говорите, если я не ошибаюсь


(Максим Таран) #14

Я, конечно, не специалист в CSS. Вообще не предполагал, что с помощью CSS можно там локаторы какие-то делать. Для меня CSS - это стили и всё. Не знал, что там есть что-то ещё.
Но походу работы часто работаю с XML и соответственно с Xpath. И для DOM-структур использовать его более наглядно и логично. Как раз для этого он и создан. Этакий микро-sql. :smile:


(sidelnikovmike) #15

Очень советую глянуть в сторону css как языка для локаторов. Мне лично - нравится и использую только его


(Mykhailo Poliarush) #16

Не, нельзя к нему так относиться. Вполне нормальный способ нахождения элементов на странице. Пол мира его используется в jquery и нормально ведь :smile: Так что для автоматизации, тоже подходит, а тем более если вы подключите sizzle или jquery, то получиться полноценная замена xpath. Просто в нативном css нет фич (например найти элемент, который содержит текст), которые есть по умолчанию в xpath. Потому я его в большей степени использую.


Был бы ли так распространен xpath без firepath?
(Tania) #17

Я считаю, что все зависит от проекта и времени, которое уделяется автоматизации.
Например, в своих тестах я использую как CSS-локаторы, так и Xpath. Причем 50 на 50.

Объясняю почему. Работаю в проекте, который недавно был стартапом. Чтобы выпустить продукт в срок на качество кода и верстки не сильно смотрели… У меня тесты написаны тогда были используя Xpath и все было хорошо до того времени, когда продукт не вышел в свет

Ребята задумались о верстке, стандартизации и усовершенствовании.
И прихожу я как-то на работу и из 115 тестов 60 упавших - это все за один вечер. Поэтому половину мне пришлось перенести на СSS, так как название классов на сайте почти не поменялось.

Не скажу, что и сейчас у нас на проекте все тихо-мирно с постоянными переносами элементов, поэтому в некоторых случаях мне приходится использовать что-то в таком стиле:

$this->сlick("xpath=(//*[contains(text(),'Сделать заказ')])");

(Michael Bodnarchuk) #18

@UaTanya В вашем примере ни CSS ни XPath не нужен, Selenium умеет находить ссылки по тексту своим нативным методом. Правда не знаю, реализован ли этот метод в PHPUnit_Selenium2TestCase (кажется вы его используете), но на будущее рекомендую посмотреть на альтернативную библиотеку php-webdriver.

Вцелом, XPath позволяет двигаться как в глубину так и в ширину по DOM дереву, в то время, как CSS только в глубину. Например, через XPath можно написать поиск элемента по его лейблу, что например, очень полезно для форм. С другой стороны, XPath крайне не удобен в обслуживании.

Так что вцелом, я считаю, что чем короче локаторы - тем лучше. В идеале, чтобы тестировщики могли прийти к верстальщикам и попросить промаркировать классами или айдишниками ключевые элементы страницы. Ибо, если локатор длинный, то что он написан на CSS, что на XPath, он может резко упасть при малейшем изменении верстки.


(Tania) #19

Спасибо, но что делать в том случае если программисты в проекте часто используют элементы, у которых каждый раз css меняется (это не их прихоть, а так нужно).
Например, вот так

css=#tableeditor-145-button_copy
css=#tableeditor-191-button_copy

и т.д.
Текста у этого элемента нет, а есть неизменяемый xpath.

Возможно для такого случая знаете лучшие решения, чем xpath?


(Michael Bodnarchuk) #20
for ($i = 100; $i<1000; $i++) {
   $el = $driver->findElement(WebDriverBy::id("#tableeditor-$i-button_copy"));
   if (!$el) continue;
}

Но не советую воспринимать это серьезно )

А вцелом да, отличное место для XPath - как ни крути, локатор тут будет короткий, плюс как раз возможность движка позволяют делать нечеткий поиск по атрибутам.