Вот что сообщают документы:
НИКОГДА не используйте xpath
Почему?
- Это самая медленная и хрупкая стратегия поиска из всех
- Разметка очень легко может быть изменена, и поэтому локаторы xpath требуют большого обслуживания
- Выражения xpath нечитаемы и их очень сложно отладить
Как сказал Майкл Кей в комментарии, эти заявления весьма самоуверенны. Я думаю, что большинство из них легко доказывают ложь.
Это самый медленный
С тех пор, как это заявление было написано, многое изменилось. Если вы сейчас тестируете XPath vs ID и CSS селекторы в лучших браузерах, вы не обнаружите большой разницы в производительности. Я только что сделал это на днях в Chrome, и эти три были практически неразличимы в 1000 поисков.
самые хрупкие
Любой плохо написанный локатор может быть хрупким. XPaths CAN должны быть написаны так, чтобы быть менее хрупкими, так же как CSS селекторы CAN должны быть написаны хрупкими. Я думаю, что XPath, вероятно, имеют тенденцию быть более хрупкими, потому что новые автоматы используют функцию копирования XPath в своем любимом браузере, который обычно создает плохие / хрупкие локаторы. Это хорошо, когда вы учитесь, но вам действительно нужно научиться писать самостоятельно. Вы, возможно, заметили, что в некоторых браузерах теперь есть опция выбора CSS-селектора ... много раз, что также делает очень хрупкими локаторы.
Если вы хотите избежать хрупких локаторов, вам нужно научиться создавать свои собственные локаторы. Для этого нужно много читать и практиковаться.
- Если ваш XPath начинается с
/html
, он хрупкий. Не делай этого.
- Если он имеет более 3-4 уровней (например,
//div/span/table/tr/td
имеет 5 уровней), то он, вероятно, более хрупкий, чем должен быть. Чем больше вы указываете, тем более жестким оно означает, что его легче сломать.
- Если вы сопоставляете строки (например,
//div[@class='alert']
), это несколько хрупко. Селекторы CSS здесь намного лучше для определения некоторых классов элемента, но не других.
- Использование индексов в локаторах может привести к хрупким локаторам, например,
//table/tr[3]/td[2]
. Что если ваши данные перемещаются в таблицу? Вы по-прежнему просматриваете строку 3, ячейку 2, а ваши данные теперь находятся в строке 4, ячейка 2. Ваш тест не пройден.
требуют много обслуживания
Вроде того же комментария, что и выше, плохо написанный селектор CSS может также потребовать много обслуживания. Напишите хороший локатор независимо от того, какой тип вы выберете, и вы сведете к минимуму обслуживание. Слишком хрупкие локаторы часто тормозят и требуют обслуживания, поэтому не пишите хрупкие локаторы. :)
выражения xpath нечитаемы и их очень трудно отлаживать
Если вы ненавидите XPath со страстью, говорите всем избегать их и никогда не используйте их сами, вы, вероятно, подумаете, что они нечитабельны и их очень трудно отлаживать. :) У них есть синтаксис, который вы должны изучить, чтобы иметь возможность читать и отлаживать их ... как селекторы CSS или любой язык программирования, который вы используете. Сказав это, XPath более многословны и более сложны, чем CSS-селекторы, но с этой дополнительной сложностью приходит больше силы.
Это то, что я использую, основываясь на моих годах с Selenium, в порядке предпочтения:
- ID
- CSS селектор
...
- 1070 * XPath *
Я использую XPath только тогда, когда у элемента нет идентификатора, и я не могу использовать селектор CSS. В основном это происходит в двух случаях: 1. когда мне нужно найти элемент на основе содержащегося текста или 2. мне нужно выполнить обход DOM (например, родитель для некоторого легко найденного элемента).
Я следую вышеприведенным правилам, и мне редко приходится обновлять локаторы, если нет существенного изменения страницы, кроме YMMV.