Недостатки приемущества xpath и почему

Вот почему мы всегда пишем селекторы на XPath

Привет, Хабр! Сегодня хочется поговорить про XPath — мощный и гибкий инструмент для работы с веб-интерфейсами, который при этом почему-то остается не особенно популярным. Статей и мануалов по XPath очень много, и в этом посте я постараюсь рассказать, как мы применяем данный инструмент и почему считаем его более эффективным, чем другие подходы. Если вам знаком термин “селектор”, а тем более — если вы слышали про XPath, добро пожаловать под кат, там много полезного!

В нашей команде работает целая группа инженеров-тестировщиков, которые ежедневно пишут автоматические end2end тесты для Selenium, а также создают огромное количество селекторов для них. С одной стороны, эта работа кажется несложной, но на практике к ней добавляются условия:

Писать код надо понятно и однотипно, потому что вы — не единственный инженер;

Всегда надо предусматривать возможность оперативно переписать селектор;

Для целого множества сайтов и версток необходимо обеспечить единый подход;

Важно гарантировать однозначность каждого селектора;

И, наконец, каждый селектор должен быть максимальную информативным.

С учетом всех этих требований, работа инженера-тестировщика становится не такой уж простой, потому что выполнять задачи необходимо с определенным уровнем унификации. И именно поэтому мы полностью отдали предпочтение XPath (XML Path Language) для написания селекторов.

Существует мнение (и оно довольно распространенное), что XPath это что-то громоздкое, со сложным синтаксисом. А некоторые также ставят под сомнение скорость поиска по XPath. Например, в одном из популярных курсов обучения по автоматизации тестирования с помощью Selenium, вы можете увидеть вот такие мысли:

Но наша практика показывает, что это не совсем так…а может быть даже совсем не так. Мы сделали ставку на XPath, потому что наша команда пишет автоматизированные тесты для заказчиков — фактически тысячи тестов. Чтобы увязать их с внедрением систем комплексного мониторинга, об этом я уже писал в прошлом посте. При таких объемах в условиях командной работы, стандартизация подходов является необходимостью, в том числе и для составления селекторов.

XPath: плюсы и минусы

Начнем с минусов — то есть с того, почему XPath не любят.

Минус №1. Холивары о скорости работы селекторов на XPath и, например, CSS действительно не затихают. Мы ввязываться в них не будем и не станем утверждать, что тот или иной подход работает быстрее. Но при этом стоит отметить, что, учитывая общее время выполнения UI теста, разница в скорости работы селектора вообще не существенна.

Минус №2. Многие считают селекторы XPath неинформативными. И это мнение обычно формируется после работы с плагинами для браузеров и стандартными средствами браузеров по поиску XPath. Действительно, селектор вида //div[1]/div[2]/ul/li/a не вызывает оптимизма. И мы, кстати, рекомендуем, не пользоваться подобными инструментами.

Минус №3. При всей мощности XPath остаются вопросы, которые он не может решить. Например, на XPath не получится сделать селекторы к псевдоклассам, и содержимому Shadow DOM. Но, как говорится, каждому инструменту — своя сфера применения.

С плюсами XPath все гораздо проще, ведь они очевидны и лежат на поверхности:

Плюс №1. Возможность поиска по тексту элемента. Первое, что мы встречаем в любом web-приложении — это текст. Текст в том числе располагается на кнопках, ссылках, выпадающих меню. И если свойства таких элементов могут измениться, то текст чаще всего останется прежним. Таким образом, даже изменения верстки никак не повлияют на XPath-селекторы.

Как следствие, через XPath можно искать элементы с изменяемым текстом. Например, если нужно выбрать в календаре “позавчера”, можно прописать дату в явном виде в селекторе XPath. Также благодаря этой функции появляется возможность создавать селекторы для сложных таблиц. Например, это будет полезно, если вам необходимо выбрать ячейку в некой строке, причем строку и столбец можно найти только по тексту, так как номера строки и столбца могут меняться.

Плюс №2. Наличие встроенных функций, таких как contains(), starts-with(), sibling, normalize-space() и прочих в совокупности с логическим операторами and, not , or позволяет создавать гибкие и универсальные локаторы.

Все это очень полезно, когда речь заходит о реальной практике. Вот 3 примера, в которых преимущества XPath видны, так сказать, невооруженным взглядом:

Пример №1. Селектор авторских постов в блоге

Берем первый попавшийся html код.

Давайте напишем селектор для <div >Ходили купаться</div>

Если делать это через CSS, то селектор будет выглядеть так: .second

Но обратите внимание, что у post1 и post3 , нет классов first и third ! Чем руководствуются разработчики подобной верстки и какие у них мотивы — мы не узнаем никогда, но с определенной долей вероятности можем утверждать, что скоро класса second тоже не будет и значит наши тесты упадут.

Сохраняя приверженность CSS, можно переписать селектор на: #post2 .title

Да, такой селектор будет жить…но вполне возможно, что тоже не долго.

Мы видим из кода, что речь идет о постах , авторских статьях или блоге. Но что будет, когда автор добавит очередной текст? Ведь логично, что новый пост должен быть первым, и тогда нумерация сдвинется, наш селектор #post2 .title будет ссылаться на пост с заголовком Как я провел лето. А неправильный селектор ещё хуже, чем нерабочий селектор, потому что узнаем мы о неправильном селекторе не сразу, если вообще узнаем.

Тем временем, на XPath селектор может выглядеть следующим образом:

//[normalize-space(.)=’Ходили купаться’ and contains(@class, ‘title’)]

Выглядит громоздко. Но сколько плюсов:

Мы привязали селектор к самому тексту заголовка, который никто не вправе изменять, кроме автора.

normalize-space(.) исключает проблему случайных/лишних пробелов.

Верстальщик может без последствий добавлять/изменять список применяемых классов — селектор останется рабочим.

И последняя, но очень важная возможность: Представьте, что перед вами задача не написать тест и селекторы, а отредактировать селектор в существующем тесте. на проде. срочно, а ещё лучше вчера…

Что проще найти и изменить, например в тысяче строк кода?

Для нас очевиден Вариант №2.

Пример №2. Поиск по DOM-дереву

Возможность поиска элементов по DOM-дереву вниз или вверх позволяет использовать XPath, чтобы добраться до самых глубоко спрятанных элементов страницы.

Возьмем реальный код

Это пример выпадающего меню на странице. Сначала нам надо кликнуть по ссылке (тег <a>), потом заполнить опцию (тег <input>), а затем выбрать ее (тег <li>). Таких меню на странице может быть несколько.

Посмотрите как изящно и однозначно выглядят селекторы XPath в таком случае:

Здесь мы оттолкнулись от существующего поля name, ушли вверх по дереву, а затем вернулись к нужным тегам. Замените значение поля name и название опции на переменные и селекторы будут универсальны для любого из меню на странице.

Пример №3. XPath справляется там, где другие не справляются

Таблицы довольно часто встречаются на web страницах. При этом нередко речь заходит о множестве таблиц на одной странице, а каждая из них может содержать сотни строк.

Ниже мы приводим только часть (упрощенного) кода.

Как сделать селектор к ссылке ячейки “На согласовании”? Классы остались где-то наверху, теги все одинаковые, атрибутов нет от слова “совсем”…XPath тут справляется “на ура”, благодаря своим функциям и полнотекстовому поиску:

Такой селектор легко читается, а значит в него легко внести правки, если это необходимо.

Кстати, тут XPath демонстрирует дополнительную гибкость. Если в примере выше “На согласовании” будет целое множество “Закупок”, то мы сможем добавить номер закупки как ещё одно условие. Например, вот так:

//*[contains(.,’Сделки’)]//tr[contains(.,’Закупка 4′)]//td[contains(.,’На согласовании’)]//a

Итого: почему именно XPath?

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

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

Подводя итог, скажу, что мы выбрали для себя XPath как наиболее удобное средство для создания селекторов и рады поделиться своим опытом как с заказчиками, так и с коллегами “по цеху”. Но не любой селектор, написанный на XPath однозначно хорош. В следующем посте я подробно расскажу о “плохих” и “хороших” практиках использования XPath, которые мы определили, набивая свои собственные шишки. А сейчас прошу всех заинтересованных поучаствовать в нашем опросе.

XPath vs CSS Selector: The Difference and How to Choose

XML path syntax uses tree diagram type flows to locate elements on an HTML page. Consider the form element in the search page markup below.

The full XPath to the search button inside the form would look like this:

As seen in the full XPath, the document is broken down into the elements that essentially represent its skeleton. Going from top to bottom within the resulting document and listing every node, until you reach the desired element, is what becomes the XPath. Here’s a shorter way to write this.

And here’s a comprehensive table for the syntax of both XPath and CSS Selectors;

XPath vs CSS Selector Syntax Table from Slotix Git Repo

What Is CSS Selector?

• Simple selectors: These search for elements based on their class or ID.
• Attribute selectors: These pick up elements based on values assigned to them. I’ll provide some examples later on in this article.
• Pseudo selectors: In situations where the states of elements are declared with CSS, such as check boxes or on-hover attributes, these come into use.

Advantages of Using CSS Selector

• It’s faster than XPath.
• It’s much easier to learn and implement.
• You have a high chance of finding your elements.
• It’s compatible with most browsers to date.

Expand Your Test Coverage

How to Create CSS Selectors

Let’s use the same image that we did earlier, with a search page’s markup displayed. You can do this on any web page by right-clicking and selecting Inspect Element. You should be able to create the CSS selector just as we did with the XPath.

In this case, the CSS selector would look like this.

Notice how much easier it is to read the CSS selector compared to the XPath. You can read this as, “The button is a child element of the div inside a form, which is itself inside the div type selector.”

To fully cover what’s possible with the CSS attribute selector, let’s consider a more specific markup example.

The selector applicable for finding specific elements in the above example would look like this.

For instance, let’s say you want to pick out the <a> element that includes “mail” as a value. In that case, you’d use the * sign after the href key. This would give you:

This returns all the elements but the first one because it doesn’t have mail as the sub-domain.

What about instances where you’d like to select all elements ending in a certain value? Then you’d replace the * with a $. You can filter out entries that start with a certain value by using the ^ sign. There are plenty of such signs depending on the rules you’re using for selection.

Now you’ve had a mini tour of each option. So which one is right for you?

Which to Use: XPath or CSS Selector?

When you’re deploying software a product to a group of users, time is often of the essence. This statement alone should let you know what option is better for you to use. If your software testers decide to make their own test automation scripts, using the option that they already have experience with is the way to go. Besides, the execution time difference between XPath and CSS selectors is not such that you could do meaningful work while others wait. Such a negligible difference means that both options may be running neck-and-neck for you at this point.

As I mentioned at the start of this article, your environment kicks in more than any other variable. A limiting factor when dealing with selectors is the fact that they get more complex as the type of element evolves from simple through pseudo to combinators. Multiple selectors would also make it more complex to even use selectors in the first place.

“There has to be a better way of implementing test automation!” you might say. As with most repetitive processes, artificial intelligence is beginning to affect both options. Services like Testim have figured out quicker and more intuitive ways to run tests on elements on the DOM.

In the past, you had to generate paths or pinpoint selectors in the back-end by combing through all the markup. Now, services such as Testim take care of that for you. The company uses its artificial intelligence and algorithms to look at the entire DOM and identify elements by multiple attributes. Testim will look at class, parent/child, color, text, type, ID, or other attributes and find the item for you to run your tests. Using such a service stops your focus from being focused on XPath vs CSS Selector. Instead, you can focus more on the results.

Also, if you use Testim, working on the front end when creating automated tests also makes it easy to deploy products faster. You can use fewer code-critical skills to iterate on the testing and feedback phase of a product’s development life cycle.

Должен ли я использовать XPath или просто DOM?

У меня есть куча иерархических данных, хранящихся в файле XML. Я использую TinyXML для обработки вручную. Учитывая фрагмент XML, который описывает сигнатуру источника как набор пар (частота, уровень), немного напоминает это:

Я извлекаю пары с этим:

где node() указывает на <source> node.

Вопрос: смогу ли я получить более аккуратный, более элегантный, более ремонтируемый или каким-либо другим способом лучший фрагмент кода с использованием библиотеки XPath?

Обновление: я пробовал его с помощью TinyXPath двумя способами. Ни один из них на самом деле не работает, что является большой точкой зрения против них. Я делаю что-то принципиально неправильно? Если это то, что будет выглядеть с XPath, я не думаю, что это приносит мне что-нибудь.

Как вторичная проблема, если это так, какую библиотеку XPath я должен использовать?

4 ответа

В общем, я предпочитаю решения на основе XPath для их краткости и универсальности, но, честно говоря, в вашем случае я не думаю, что использование XPath принесет много вашего signature .

Элемент элегантности
Ваш код хорош и компактен, и он не будет лучше с выражением XPath.

Память
Если ваш входной файл конфигурации XML не является огромным (своего рода оксюморон), а разбор DOM повлечет за собой большой объем памяти, для которого нет доказательств того, что использование XPath было бы решающим средством, я бы придерживался DOM.

Скорость выполнения
На таком простом дереве XML скорость выполнения должна быть сопоставимой. Если бы была разница, вероятно, это было бы в преимуществе TinyXml из-за коллокации тегов freq и level при заданном node.

Библиотеки и внешние ссылки. Это решающий момент.
Ведущий движок XPath в мире С++ XQilla. Он поддерживает XQuery (поэтому и XPath 1.0 и 2.0), и подкрепляется Oracle, потому что он разработан группой, ответственной за продукты Berkeley DB (в том числе именно Berkeley DB XML, который использует XQilla).
Проблема для разработчиков С++, желающих использовать XQilla, заключается в том, что у них есть несколько альтернатив

• используйте Xerces 2 и XQilla 2.1, помещая ваш код приложением.
• используйте XQilla 2.2+ и используйте Xerces 3 (здесь не требуется никаких бросков)
• используйте TinyXPath, прекрасно интегрированный с TinyXml, но для которых, однако, существует ряд ограничений (например, поддержка пространств имен)
• mix Xerces и tinyXml

В общем, в вашем случае переход на XPath только ради этого принесет мало пользы, если таковой имеется.

Тем не менее, XPath — очень мощный инструмент в сегодняшней панели инструментов разработчика, и никто не может его игнорировать. Если вы просто хотите попрактиковаться на простом примере, то вы так же хороши, как и все. Затем я буду иметь в виду вышеописанные пункты и, возможно, использовать TinyXPath.

Введение в XPath

Язык разметки XML с самого первого стандарта окружает пользователей компьютеров. Таблицы в Excel, выгрузки из интернет-магазинов, RSS-ленты с новостями — все это основано на XML. Хоть визуальное отображение отличается на устройствах и в программах, но в основе всегда лежит единый формат.

Внутри XML-файла может находиться огромное количество информации, поэтому и встает вопрос о перемещении и выборке внутри документа. Как это сделать быстро? Какие средства применять, чтобы в интернет-магазине найти нужный товар из десятков тысяч других? Для навигации и поиска внутри XML используется язык запросов XPath.

В этой статье разберем:

• для кого может быть полезен XPath
• базовые конструкции языка для поиска информации в XML
• чем XPath отличается от CSS-селекторов при поиске в HTML

Синтаксис XPath

Для начала создадим базовый пример XML, с которым и будем работать весь урок. Например, список курсов по верстке на Хекслете в XML будет выглядеть так:

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

Для тестирования результата подойдут такие онлайн-сервисы, как:

Абсолютные пути

Самый простой запрос состоит из обращения к корневому элементу. Для этого достаточно выполнить запрос /courses . Нам вернется XML в почти таком же виде, что и в примере выше. Обратите внимание на строку <?xml version="1.0" encoding="UTF-8"?> . Она отличается, потому что элемент не внутри <courses> :

В качестве результата XPath возвращает узлы XML-документа.

Продолжим цепочку и обратимся к описанию из элемента <description> . Для этого добавим в запрос путь к description : /courses/description . Результатом выполнения станет:

Путь, который строится от корневого элемента, называется абсолютным. Используем схему из прошлого запроса и обратимся к любому элементу внутри XML.

Попробуем обратиться к имени курса. В этом случае вернется поле <name> из всех курсов. Запрос /courses/course/name вернет:

Вот список некоторых базовых запросов и их результат:

Относительные пути

Прошлые запросы строились с помощью абсолютных путей — то есть мы указывали полный путь до информации. Бывают ситуации, когда полный путь не подходит: например, мы хотим обраться к какому-то уникальному полю или не знаем полный путь. В этом случае можно использовать относительный путь — он произведет поиск по всему XML и вернет узлы, подходящие под запрос.

Чтобы записать относительный путь, нужно использовать конструкцию // . После нее можно написать любое поле и получить результат. Например, //name вернет поля <name> из всего XML:

Проблема такого подхода — уникальность полей. В документах одни и те же имена полей могут обозначать разные данные в зависимости от расположения. Поэтому используйте относительные пути только там, где уверены в возвращаемых данных. Например, в нашем примере название курса может быть заключено в <title> :

Запрос //title вернет не только имена курсов, но и узел, который находится в <courses> :

Чтобы сэкономить пару секунд, разработчики опускают корневой элемент и пользуются относительными путями. Например, вместо /courses/course/name они пишут //course/name . Для практики попробуйте прошлые примеры перевести на относительные пути с помощью такого механизма.

Несколько примеров запросов с идентичными ответами, как и в прошлой таблице:

Предикаты

В примерах запросов к именам возвращались имена всех найденных курсов. В некоторых ситуациях это может быть избыточно. Что делать, если хочется получить данные только по первому курсу в <courses> ? На помощь приходят предикаты — конструкции, с помощью которых можно отфильтровать элементы по заданным условиям.

Выберем ключевые слова первого курса по верстке. Для этого достаточно использовать запрос //course[1]/tags :

Обратите внимание на [1] . Это предикат с таким условием: «Взять элемент по индексу 1». Попробуйте сделать запрос ко второму или третьему элементу. Достаточно поменять всего одну цифру!

В XPath индексы элементов начинаются с единицы, а не с нуля, как в принятых стандартах программирования. Если вы уже программируете, это может немного запутать.

Предикаты помогают делать точные выборки. Например, получить ссылки на русскоязычные страницы курсов. Для этого нужно получить элементы <url> , у которых атрибут lang равен ru . Делается это указанием атрибута и значения. Чтобы XPath отличил атрибут от элемента перед атрибутом указывается символ @ .

Теперь запрос будет выглядеть так: //course/url[@lang="ru"]

Иногда полезно выбрать элементы, которые имеют хоть какой-то атрибут. Для этого можно использовать конструкцию //*[@*] :

По примеру выше видно, знак * обозначает «все/любой».

Когда выбраны элементы по атрибутам, можно произвести дополнительную фильтрацию по этим значениям. Например, найдем элементы <duration> со значением атрибута value больше 9 . Внутри предикатов используются операторы сравнения, знакомые по языкам программирования:

• > — больше
• < — меньше
• >= — больше или равно
• <= — меньше или равно
• = — равно
• != — не равно

Запрос будет выглядеть так: //course/duration[@value > 9] :

Мы разобрались, как выбирать одно поле — это интересная, но редкая задача. Чаще разработчики обрабатывают данные по всему файлу или нескольким полям. Попробуем одновременно использовать предикат и обратиться к другим полям. Обратите внимание на два момента:

• Предикат необязательно должен идти в конце запроса
• Внутри предиката могут находиться новые пути, которые нужно проверить

Мы уже знаем, как с помощью предиката отфильтровать данные по полю <duration> . Эту задачу мы выполняли с помощью конструкции duration[@value > 9] . А теперь попробуем сделать эту конструкцию предикатом для <course> . Так мы получим данные о курсах с длительностью больше 9 часов: //course[duration[@value > 9]] :

Можно продолжить этот запрос и получить только имена курсов. Тогда предикат будет в середине запроса, а не в его конце: `//course[duration[@value > 9]]/name

Функции

В прошлых примерах запросы затрагивали теги и атрибуты. Сами данные мы не затрагивали, хотя это огромный пласт информации, по которой можно делать выборки. Для решения этой задачи используются встроенные в XPath функции. Они являются частью предикатов — например, @ . Попробуем найти курс с названием «Основы верстки контента».

Для поиска по тексту внутри элемента используется функция text() . Ее задача — получить текстовое значение элемента и сравнить его с условием по необходимости. Вот как будет выглядеть запрос для поиска курса с нужным именем: //course[name[text()="Основы верстки контента"]]

Но что, если нам известно только часть названия? Для этого существует функция contains() , которая принимает два аргумента:

1. Строка, где будет производиться поиск
2. Подстрока, которая будет искаться

Для примера найдем курс, у которого в ключевых словах есть слово «Bootstrap». Функция примет текстовое значение элемента tags и найдет там слово «Bootstrap»: //course[tags[contains(text(), "Bootstrap")]]

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

Отличия от CSS-селекторов

Если вы писали на JavaScript, то знаете, что элементы можно искать с помощью CSS-селекторов, используя методы querySelector() или querySelectorAll() . Почему же разработчики иногда ищут элементы внутри HTML именно с помощью XPath?

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

Если вы хотите подробнее изучить поиск по HTML с помощью XPath, рекомендуем обратиться к статье Introduction to using XPath in JavaScript.

С помощью CSS нельзя найти все элементы div , внутри которых есть ссылки — можно найти сами ссылки, но не их родителей. XPath позволяет это сделать простым сочетанием div[a] . Постепенно ситуация меняется: в CSS появился селектор :has() , но он поддерживается еще не всеми новыми версиями браузеров. Со временем это изменится, но пока реальность именно такая.

Другой пример — поиск элементов по тексту внутри них. С этой задачей CSS никогда не справится, так как такой цели у него нет. XPath, как мы изучили, умеет это делать с помощью функции text() .

Кому нужен Xpath

Если коротко, Xpath нужен всем, кто работает с XML.

Чтобы разобраться подробнее, изучим несколько примеров:

SEO-специалисты. Специалисты по продвижению часто обрабатывают большие массивы данных и вытаскивают информацию со страниц сайта.

Например, для них критичны мета-теги — дополнительная информация, в которой содержатся иконки сайтов, название страницы, описание и так далее. Эту информацию SEO-специалист может автоматически парсить с помощью запросов в XPath.

Тестировщики. При работе с Front-end тестировщики часто проверяют тот или иной вывод информации на странице — для этого они выбирают отдельные элементы с нужной страницы. Это можно делать через XPath и DevTools, встроенный в браузеры на основе Chromium.

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

Это лишь часть сценариев, в которых пригождается язык XPath — на самом деле, их десятки.

Заключение

В этой статье мы рассмотрели, где встречается XML и кому он может пригодиться. Мы научились составлять базовые запросы и изучили часто используемые конструкции XPath:

• Абсолютные и относительные пути
• Предикаты
• Поиск по атрибутам
• Операторы сравнения
• Функции

Также теперь вы знаете, что поиск по HTML с помощью XPath может быть эффективнее поиска с помощью CSS-селекторов.

В этой статье мы постарались дать знания, которые помогут справиться с большинством задач. Но это далеко не все возможности XPath — это более глубокий язык, чем представлено в статье. Как и с другими технологиями, тут важно набить руку. Чем больше вы практикуетесь, тем более точные и полезные запросы пишете.