Всем доброго времени суток.
Не так давно в одной из тем я задал вопрос - почему во многих примерах на форуме наши коллеги используют xpath? почему не css?
Ответа я сразу не получил, и очень хотелось бы услышать некоторые мысли по этому поводу.
В свою очередь я немного посидел и посмотрел на некоторые аспекты этих 2-х способов. Свои мысли изложил у себя здесь - Automated testing blog: Selenium - CSS или XPath?
Было бы интересно подискутировать. Разумеется, без холивара 
@sidelnikovmike на первый взгляд, очень интересное исследование.
Почитаю вечерком.
А пока, могу предложить добавить ссылку на ваш пост в АвтоХомяк
Могу еще предложить добавить блог в “трансляцию блогов” на software-testing.ru
Как, описано тут . Так, вы сможете привлечь больше читателей.
Не всегда есть id, class и т. д.
Порой единственный способ найти элемент — это его xpath.
Чтобы не плодить сущности я всегда использую xpath.
p. s.: УРАААА!!! Добавили автоперевод строки в комментариях!
Спасибо!
Насчет “хомяка” - я только за!
Насчет трансляции - вдвойне спасибо! Доберусь до компьютера - обязательно сделаю.
Да, разумеется.
А ре могли бы вы привести какой-нибудь пример? Из достаточно часто используемых? Было бы интересно.
Например, ссылка со случайным текстом внутри.
testomat.io управление авто тестами<a href="messages">%count% new messages</a>
Порой такой элемент можно найти только через XPath, т. к. метод поиска по тексту не подходит, атрибуты id и class у элемента отсутствует.
Итого для explorer: вот тут сильно разнятся, причем проигрывает CSS. Чуть ли не в 2 раза. Если честно - я не ожидал.
Очень даже странно, может быть я уже чего-то не понимаю, но должно быть как раз наоборот.
Но я в своей практике, также очень часто использую xpath (когда нет id), потому что он мне дает все необходимые возможности достать элементы, независимо от того, есть там какие-то аттрибуты или нет.
Да, меня explorer тоже удивил. Я не раз проверил, но результат именно такой получился
Мне тут подумалось насчет того, почему CSS-локаторы рекомендуют. Возможно потому, что UI-разработчики именно их используют для поиска элементов через JS, следовательно, и для
автотестов они подойдут. А по наглядности CSS-локатор более краткий получается.
Хотя, я использую только XPath-локаторы. Просто по-привычке. А так же по причине, которую уже озвучил @TIT - для единообразия
xpath вроде лучше поддерживается таким старьем как IE6. По работе приходилось автоматизировать под него на QTP, и в IE6 не всегда работали CSS селекторы, пришлось от них полностью отказаться.
@joemast согласен про использование и краткость. Но всегда ли краткость - это хорошо?
Я бы сказал, что css просто популярнее. Во многом из за jquery, как мне кажется.
@rmerkushin - ага , я тоже слышал, что в некоторых версиях IE проблемы с поддержкой CSS.
я считаю что да, потому что когда вы автоматизируете веб-приложения, то локаторы должны быть как можно короче, для того чтобы исключить моменты превращения локаторов в неработающие чисто потому что dom модель каким-то образом поменялась (хотя самое внешние представление может и не поменяться)
краткость, как мне кажется, не есть оптимальность. Вы скорее про второе говорите, если я не ошибаюсь
Я, конечно, не специалист в CSS. Вообще не предполагал, что с помощью CSS можно там локаторы какие-то делать. Для меня CSS - это стили и всё. Не знал, что там есть что-то ещё.
Но походу работы часто работаю с XML и соответственно с Xpath. И для DOM-структур использовать его более наглядно и логично. Как раз для этого он и создан. Этакий микро-sql. 
Очень советую глянуть в сторону css как языка для локаторов. Мне лично - нравится и использую только его
Не, нельзя к нему так относиться. Вполне нормальный способ нахождения элементов на странице. Пол мира его используется в jquery и нормально ведь Так что для автоматизации, тоже подходит, а тем более если вы подключите sizzle или jquery, то получиться полноценная замена xpath. Просто в нативном css нет фич (например найти элемент, который содержит текст), которые есть по умолчанию в xpath. Потому я его в большей степени использую.
Я считаю, что все зависит от проекта и времени, которое уделяется автоматизации.
Например, в своих тестах я использую как CSS-локаторы, так и Xpath. Причем 50 на 50.
Объясняю почему. Работаю в проекте, который недавно был стартапом. Чтобы выпустить продукт в срок на качество кода и верстки не сильно смотрели… У меня тесты написаны тогда были используя Xpath и все было хорошо до того времени, когда продукт не вышел в свет
Ребята задумались о верстке, стандартизации и усовершенствовании.
И прихожу я как-то на работу и из 115 тестов 60 упавших - это все за один вечер. Поэтому половину мне пришлось перенести на СSS, так как название классов на сайте почти не поменялось.
Не скажу, что и сейчас у нас на проекте все тихо-мирно с постоянными переносами элементов, поэтому в некоторых случаях мне приходится использовать что-то в таком стиле:
$this->сlick("xpath=(//*[contains(text(),'Сделать заказ')])");@UaTanya В вашем примере ни CSS ни XPath не нужен, Selenium умеет находить ссылки по тексту своим нативным методом. Правда не знаю, реализован ли этот метод в PHPUnit_Selenium2TestCase (кажется вы его используете), но на будущее рекомендую посмотреть на альтернативную библиотеку php-webdriver.
Вцелом, XPath позволяет двигаться как в глубину так и в ширину по DOM дереву, в то время, как CSS только в глубину. Например, через XPath можно написать поиск элемента по его лейблу, что например, очень полезно для форм. С другой стороны, XPath крайне не удобен в обслуживании.
Так что вцелом, я считаю, что чем короче локаторы - тем лучше. В идеале, чтобы тестировщики могли прийти к верстальщикам и попросить промаркировать классами или айдишниками ключевые элементы страницы. Ибо, если локатор длинный, то что он написан на CSS, что на XPath, он может резко упасть при малейшем изменении верстки.
Спасибо, но что делать в том случае если программисты в проекте часто используют элементы, у которых каждый раз css меняется (это не их прихоть, а так нужно).
Например, вот так
css=#tableeditor-145-button_copy
css=#tableeditor-191-button_copy
и т.д.
Текста у этого элемента нет, а есть неизменяемый xpath.
Возможно для такого случая знаете лучшие решения, чем xpath?
for ($i = 100; $i<1000; $i++) {
$el = $driver->findElement(WebDriverBy::id("#tableeditor-$i-button_copy"));
if (!$el) continue;
}
Но не советую воспринимать это серьезно )
А вцелом да, отличное место для XPath - как ни крути, локатор тут будет короткий, плюс как раз возможность движка позволяют делать нечеткий поиск по атрибутам.