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

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

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

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

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

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

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

1 лайк

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

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

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

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

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

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

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

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

1 лайк

Спасибо, но что делать в том случае если программисты в проекте часто используют элементы, у которых каждый раз 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 - как ни крути, локатор тут будет короткий, плюс как раз возможность движка позволяют делать нечеткий поиск по атрибутам.

Идеальный мир для селениума - все элементы имеют постоянные id:)

4 лайка

А что вам мешало использовать только название элементов и классы в xpath? Все что вы можете написать на css вы можете точно также написать на xpath. А то что у вас тесты упали, так это просто показывает гибкость ваших локаторов.

Вот можете просто привести пример локаторов, которые вы перевели из xpath в css и указать почему вы их перевили в такой вид?

Эффективные и гибкий локаторы - это прямой результат эффективной совместной работы тех кто автоматизирует и верстальщиков с программистами. Можно просто плыть по течению и писать локаторы, которые получаются. А можно взять волю в кулак и решить проблемы организационно, при этом решая неявно вопросы уникальности, гибкости и поддержки локаторов.

Так нужно тогда использовать другие элементы, которые могут задать уникальность локатора. Тут вот как раз css или xpath в помощь. Или программно высчитывать id как указал @davert

Понятно, что такого идеального мира тяжело найти, но поверьте в наших силах поменять это. Просто надо задаться целью, вот и все.

1 лайк

Ну и @dzhariy ушел немного в сторону указав примеры создания локаторов с разными javascript библиотеками используемыми в веб-приложении, подключаемся к обсуждению.

Полностью согласен. Успех достигается лишь совместной работой.

Ага, только разрабам, как правило, пофиг, либо же они в принципе не знаю как устроен framework, работая с ним только на уровне реализуемого языка.

Вот интересно, как отличается скорость на мобильных броузерах, поддерживающих и css и xpath.

Давай проверим?

Ну в любом случае xpath позволяет сделать все то-же и еще немного по сравнению с css :smile:
Все достаточно доходчиво было описано в вебинаре миши про гибкие локаторы.
к примеру частенько встречается такая вот радость набор из таких вот блоков:

<div>
      <label>Some Text Label</label>
      <input>type="text"</label>
</div>

то для xpath метод получения текстового поля с таким шаблоном будет такой:

public WebElement getTextField(String label){
    return driver.findElement(
           By.xpath(".//label[contains(text(), '"+label+"')]/parent::div//input"));
}

при желании можно еще и на запчасти разобрать.
А вот как подобное сделать с помощью css?

contains – это конечно, сейчас – железный аргумент. Такой селектор, аля input:contains(text) планировался в CSS3, но в итоге – потерялся и не вошел в спецификацию.

Да, преимущество XPath в том, что на нем однозначно можно идентифицировать любой элемент, тем не менее, можно и совмещать CSS селекторы для простых вещей и XPath для более сложных. Я предпочитаю такой вариант

2 лайка

Тут дело даже на в contains, а в /parent::, /ancestor::