testomat.io управление авто тестами@joemast согласен про использование и краткость. Но всегда ли краткость - это хорошо?
Я бы сказал, что css просто популярнее. Во многом из за jquery, как мне кажется.
@rmerkushin - ага , я тоже слышал, что в некоторых версиях IE проблемы с поддержкой CSS.
я считаю что да, потому что когда вы автоматизируете веб-приложения, то локаторы должны быть как можно короче, для того чтобы исключить моменты превращения локаторов в неработающие чисто потому что dom модель каким-то образом поменялась (хотя самое внешние представление может и не поменяться)
краткость, как мне кажется, не есть оптимальность. Вы скорее про второе говорите, если я не ошибаюсь
Я, конечно, не специалист в CSS. Вообще не предполагал, что с помощью CSS можно там локаторы какие-то делать. Для меня CSS - это стили и всё. Не знал, что там есть что-то ещё.
Но походу работы часто работаю с XML и соответственно с Xpath. И для DOM-структур использовать его более наглядно и логично. Как раз для этого он и создан. Этакий микро-sql. 
Очень советую глянуть в сторону css как языка для локаторов. Мне лично - нравится и использую только его
Не, нельзя к нему так относиться. Вполне нормальный способ нахождения элементов на странице. Пол мира его используется в jquery и нормально ведь Так что для автоматизации, тоже подходит, а тем более если вы подключите 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
Все достаточно доходчиво было описано в вебинаре миши про гибкие локаторы.
к примеру частенько встречается такая вот радость набор из таких вот блоков:
<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::