Комментарии 16
Что-то вы про абсолютные и относительные написали нечто странное. Абсолютные XPath начинаются с /, относительные - все остальные.
Когда вы ищете элемент в документе начиная с корня - разницы между относительным и абсолютным xpath нет, но вот при более точном поиске - есть. Или, к примеру. в предикатах обычно используют именно относительные xpath, по понятным причинам.
del
Здесь скорее напоминание о том, что есть абсолютный и относительный пути. И далее разъяснения, почему используем так, а не иначе. О некоторых моментах теории я упоминаю, но в целом для хорошего понимания наших практик необходимо знать базу.
Не все пути, что начинаются с / абсолютные, никто не мешает дальше использовать относительный /html/body//div. На этом же примере не соглашусь с мыслью, что нет разницы между путями, когда ищем с корня.
Только вот путь /html/body//div - абсолютный, а не относительный. Он всегда вычисляется относительно корня документа, а не относительно context node
Поясню на примере. Обычно у нас много элементов на странице, такой путь покажет далеко вложенные div, что по определению абсолютным путем не является (но также может оказаться равному абсолютному=полному html/body/div). Можно на сайте ok.ru (без логина) ввести в консоль разработчика /html/body/li и /html/body//li, результаты будут разные. В первом случае 0, нет такой комбинации, когда за body идет li, а во втором случае не 0. Абсолютный путь не только начинается с /, но и указывает на полный путь до элемента.
Да, результаты будут разные. Нет, абсолютность пути тут ни при чём.
Поясняю на примере. Возьмём вот такой документ:
<root>
<foo>
<bar />
</foo>
<bar />
</root>
Рассмотрим путь //bar. По этому пути найдётся два элемента, если идти от корня. И если идти не от корня, а от элемента foo - всё равно найдётся два элемента, потому что путь абсолютный.
Теперь рассмотрим путь .//bar. По этому пути найдётся два элемента, если идти от корня. И всего один элемент если идти от элемента foo Потому что путь относительный.
Спасибо за ваши комментарии и желание разобраться, но давайте, наверное, закончим дискуссию, мы с вами используем разную терминологию. В определение путей вы вносите ещё и логику работу с осями в XPath, но мы до этого говорили именно про абсолютный и относительный путь. Если добавлять работу с осями, то у нас появляется дополнительная логика. Так вы приводите пример работы с поиском от контекста и работой с осью self, когда обращаетесь с помощью «.»
Да, разумеется, мы используем разную терминологию. Именно в этом и проблема: я использую официальную, а вы свою непонятно откуда взяли.
К сожалению, именно вы руководствуетесь неофициальной терминологией. Мы берем определения из официальной документации, не смешиваем и не подменяем понятия. Ещё раз спасибо за дискуссию, а те, кто будут читать этот тред могут самостоятельно обратиться к официальным определениям.
Не понимаю почему очевидные вещи приходится доказывать с таким трудом, но всё же. Идём в самую официальную документацию - https://www.w3.org/TR/xpath-3/#id-path-expressions - и видим:
A path expression that starts with "/" or "//" selects nodes starting from the root of the tree containing the context item; it is often referred to as an absolute path expression.
А вот вы какими такими официальными источниками пользовались?
В заголовке сказано про стабильность, в тексте ни слова о стабильности.
Не было целью рассказать всё про стабильность, это отдельная большая и серьезная тема. Есть поинты, которые мы можем учесть на этапе проектирования, есть те, которые возникают уже в моменте. Цель как раз таки рассказать, как в самом начале с помощью качественных локаторов (в том числе по правилам, изложенным в статье) можно добиться стабильности и уберечь свои автотесты от флаков на этапе их написания. Это как одна из самых простых и понятных возможностей.
Да правила в общем те же, только всё равно есть моменты, когда без цифр не обойтись.
Например, вам нужен текст из ячейки какой-нибудь таблицы, все ячейки однотипные, текст в них может быть разным. Там последовательность вообще в принципе единственная характеристика, по которой можно ориентироваться.
Если у вас есть подборка в открытом доступе по правилам с разъяснениями, почему так стоит делать, а не иначе, поделитесь с нами, пожалуйста:) Действительно есть такое, что иногда без цифр не обойтись. Ваш пример корректен. В данной статье не стала рассматривать, это не наш частый кейс. Всё же отмечу, что в больших и динамических проектах они встречаются не часто. Внутренние сервисы (админки, например) могут выглядеть как большие таблицы, локаторы к которым легче написать через цифры. Но обычно на такие проекты достаточно небольшого количества смоуков для проверки базовой функциональности. И ресурсов на поддержание и написание таких тестов отводится крайне мало.
Залог стабильных автотестов (да и то, малая часть этого залога, если честно) - это стабильные локаторы, а не xpath/css/whatever.
Несколько странно не увидеть от продуктовой компании рекомендации №0 (которая, впрочем, и единственная) - развешивайте кастомные атрибуты над элементами, с которыми взаимодействует тест, причем название атрибутов не имеет значения. Хотя если придерживаться распространенного названия `data-testid`, современные инструменты (например, playwright) смогут вам сгенерировать локаторы автоматически.
В статье упоминается об этом «Но ещё вы можете добавлять свои тестовые ID, с которыми можно будет работать в рамках автотеста.» Однако такой совет применим не ко всем. У вас может не быть возможности добавить их в исходный код . Тогда не очень понятно, как развешивать тестовые атрибуты. И статья вовсе не об этом:) Цель была показать наши практики работы с Xpath, которые на уровне написания автотеста помогут уберечь тест от флаков на этой основе. Только для написания вам нужны базовые знания, а договариваться с отделом разработки и исходный проект не нужен. Это действительно небольшой залог стабильности автотестов, но его тоже нужно учитывать.
Xpath — залог стабильных UI-автотестов на Web и Mobile Web