@UaTanya В вашем примере ни CSS ни XPath не нужен, Selenium умеет находить ссылки по тексту своим нативным методом. Правда не знаю, реализован ли этот метод в PHPUnit_Selenium2TestCase (кажется вы его используете), но на будущее рекомендую посмотреть на альтернативную библиотеку php-webdriver.
Вцелом, XPath позволяет двигаться как в глубину так и в ширину по DOM дереву, в то время, как CSS только в глубину. Например, через XPath можно написать поиск элемента по его лейблу, что например, очень полезно для форм. С другой стороны, XPath крайне не удобен в обслуживании.
Так что вцелом, я считаю, что чем короче локаторы - тем лучше. В идеале, чтобы тестировщики могли прийти к верстальщикам и попросить промаркировать классами или айдишниками ключевые элементы страницы. Ибо, если локатор длинный, то что он написан на CSS, что на XPath, он может резко упасть при малейшем изменении верстки.
Спасибо, но что делать в том случае если программисты в проекте часто используют элементы, у которых каждый раз css меняется (это не их прихоть, а так нужно).
Например, вот так
for ($i = 100; $i<1000; $i++) {
$el = $driver->findElement(WebDriverBy::id("#tableeditor-$i-button_copy"));
if (!$el) continue;
}
Но не советую воспринимать это серьезно )
А вцелом да, отличное место для XPath - как ни крути, локатор тут будет короткий, плюс как раз возможность движка позволяют делать нечеткий поиск по атрибутам.
А что вам мешало использовать только название элементов и классы в xpath? Все что вы можете написать на css вы можете точно также написать на xpath. А то что у вас тесты упали, так это просто показывает гибкость ваших локаторов.
Вот можете просто привести пример локаторов, которые вы перевели из xpath в css и указать почему вы их перевили в такой вид?
Эффективные и гибкий локаторы - это прямой результат эффективной совместной работы тех кто автоматизирует и верстальщиков с программистами. Можно просто плыть по течению и писать локаторы, которые получаются. А можно взять волю в кулак и решить проблемы организационно, при этом решая неявно вопросы уникальности, гибкости и поддержки локаторов.
Так нужно тогда использовать другие элементы, которые могут задать уникальность локатора. Тут вот как раз css или xpath в помощь. Или программно высчитывать id как указал @davert
Понятно, что такого идеального мира тяжело найти, но поверьте в наших силах поменять это. Просто надо задаться целью, вот и все.
Ну и @dzhariy ушел немного в сторону указав примеры создания локаторов с разными javascript библиотеками используемыми в веб-приложении, подключаемся к обсуждению.
Ну в любом случае 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 для более сложных. Я предпочитаю такой вариант
Идея не совсем моя… Я имею ввиду для теста, в котором надо нажать на кнопку “Обучение” вверху страницы и проверить работает она или нет - понадобиться локатор этой кнопки. Можно написать простой локатор, который будет хвататься за кнопку. А можно сделать в локатеоре валидацию:
Теперь ясно. Ну, мне кажется, такой подход имеет право на существование, если есть уверенность, что xpath не будет сильно меняться со временем. Иначе тесты будут часто падать от любого чиха, а вместо простого обновления локаторов, нужно будет заново все взаимосвязи учитывать.