XPath. Как выбрать невложенный элемент, следующий за искомым

программирование
#1

Добрый день.
Вопрос сформулирован довольно странно, сейчас попробую объяснить, что мне надо.
HTML выглядит примерно так:

<li>
    <a id="agentMenu:xxx">Раздел</a>

    <ul>
      <li>
        <a id="agentMenu:yyy">Подраздел 1</a>
      </li>
      <li>
        <a id="agentMenu:zzz">Подраздел 2</a>
      </li>
    </ul>

</li>

Как мне прописать XPath, чтобы взять список подразделов в конкретном разделе?
Я могу найти ссылку таким образом:

//*[contains(@id, 'agentMenu') and text()='Раздел']

Но как потом выбрать подразделы, я что-то не соображу…

#3

на стэковерфлоу нашел что-то, может поможет:

JavaScript:

WebElement myElement = driver.findElement(By.id(“myDiv”));
WebElement parent = (WebElement) ((JavascriptExecutor) driver).executeScript(
“return arguments[0].parentNode;”, myElement);

XPath:
WebElement myElement = driver.findElement(By.id(“myDiv”));
WebElement parent = myElement.findElement(By.xpath("…"));

Не очень силен в xpath, но мне кажется можно для элемента найти его parent и у него уже взять по определенному локатору child’ов

2 лайка
#4

Спасибо, чот я затупорылил.
Сделал так:

//*[contains(@id, 'agentMenu') and text()='Раздел']/../ul/li

Теперь всё работает.

#5

//*[contains(@id, ‘agentMenu’) and text()=‘Раздел’]//li

так проще)

#6

Может и проще - но неправильно.

#7

Если на то пошло то и //*[contains(@id, ‘agentMenu’) and text()=‘Раздел’]/…/ul/li ужасный селектор малейшие изменения в структуре или названиях и все.

#8

А вот с этим согласен - можно сделать и по стабильнее.
В принципе ответ есть уже в названии темы.

#9

//*[contains(@id, ‘agentMenu’) and not (contains(@id, ‘xxx’))]/parent::li слишком закручено, но хотя бы к тексту не привязано. А вообще надо просить програмеров добавлять айдишники везде куда вам нужно. Или сами добавляйте. Это не сложно. Или как вариант css классы вешать на на строки, что бы по класснейму можно было достать необходимые строки

#10

Вопроса об использовании текста элемента или нет - у ТС нету.
Далеко не всех устраивает получить зеленый тест, когда вместо текста “Разделы” в приложении будет “Ыледзар”.

#11

Так проще, но не работает.
А программеров просить что-либо добавлять у меня возможности нет, да и сам добавить не могу. Приходится работать с тем, что дают.
А название раздела там берётся из метода, который выбирает его случайным образом по айдишнику, так что смена названия повлиять не должна, а вот смена айдишников повлиять может. Самое печальное, что айдишники могут поменяться…

#12

Ну так обычно когда человек пишет тест, он видит все эти кнопки и названия. Когда тестов 10, тогда еще ладно. Но когда тестов пару тысяч и огромный тестовый фреймворк, искать почему упал тест, исправлять каждый раз селектор из-за смены кемто текста, как по мне глупо.

#13

Так я же говорю, смена текста не повлияет.
А на смену айдишников я повлиять никак не могу.

#14

Печально) Ну в таком случае вариантов не много)

#15

Если есть [quote=“alexkuzpro, post:12, topic:4490”]
тестов пару тысяч и огромный тестовый фреймворк
[/quote], то на таком проекте должны быть ТЗ/спецификации/реквайроменты. Если кто-то/где-то/[не]умышленно поменял текст - это либо баг, либо изменилось ТЗ. И на это изменение система тестирования (как мануальная, так и автоматизированная) должна реагировать - либо пишем баг, либо апдейтим тесты. А вот если кто-то/где-то поменял id (а представьте что все id в аппе изменились :wink: - а че долго что ли - обфусцировали/отрефакторили бд) и тест упал - то вариант “пишем баг” отпадает и все становится печально.
И искать почему упал тест, как впрочем и исправлять его, много легче глядя на скриншот фейла, чем копаться в сорсе.

#16

Почитайте http://www.w3schools.com/xpath/xpath_axes.asp

В данном случае вам нужен following-sibling

#17

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

#18

Неубедительно. Предлагаю вам самостоятельно поразмышлять о достатках и недостоинствах данных подходов - у меня слишком много аргументов, что бы оффтопить в данной ветке.

#19

Я с радостью поразмышляю, но за последние пол года, в проекте с котором я работаю не изменился ни один айдишник. А вот текст и страницы менялись частенько. Мне просто интересно в каких ситуациях и для чего менять айди каких то элементов на странице? Касатально проверки текста в каких-то элементах, то если это необходимо, то логичней это проверять осознанно именно Assert’ом, а не тем что элемент не найден на странице. Если есть необходимость проверить текст, для этого можно сделать отдельный тест. Который может упасть если текст неправильный или его изменили. А вот когда падают 1000 тестов перед апдейтом из-за того что изменили название кнопки, это полный бред.

#20

Это вне компетенции QA. Любой программист в любой момент может взять да изменить, и запрашивать аппрув на это он ни у кого не должен - это их вотчина. Хотите сложный пример? Апп на gwt - надо запустить скрипты на проде, где отключен debug mode.[quote=“alexkuzpro, post:19, topic:4490”]
А вот когда падают 1000 тестов перед апдейтом из-за того что изменили название кнопки, это полный бред.
[/quote]А я скажу - круто. Отрепортаю, что 50% тестов failed из-за изменений в GUI. Не выпущу билд. Начну разбираться с мануальщиками/менеджерами/кастомерами кто/зачем/почему это сделал. И если это запланированное изменение, а не дефект - за пару секунд, не открывая страницу в браузере, его исправлю. Те же действия проделают мануальщики со своими тест-кейсами.
А вот если те же 1000 ТК упадут по причине изменившегося id (ну не понравился девелоперу Ване этот id) - репортать будет нечего. Вы фиксите “молча”. Это занимает многим более пары секунд. Запускаете снова. Часть опять падает - на этот раз виноват кто-то другой. Время идет. Начальство нервничает/подгоняет. Репорта все-еще нету. Наконец все passed. Вы выпускаете билд, который через пару минут “заворачивает” отдел QA, потому что кнопки “Войти” и “Отмена” обменялись функционалом.

#21

Не везде так. В том то и разница между тестером и QA. Нормальные QA непосредственно участвуют в разработке приложения, обсуждениях функционала и тд. Т.е. мы просто говорим о разных профессиях. Я так и не увидел убедительной надобности вдруг просто так менять айдишники например на инпутах. А если програмер делает что ему угодно, как угодно и команда не общается между собой, то это ничем не отличается от удаленной работы на одеске.

И вы потратите драгоценное время. Тесты не 5 минут идут. А упав на кнопке, они не протестировали что то другое. Повторно запускать, это лишнее потраченное время.

Насчет не понравился id, я уже написал. Это не корректно и неправильно. А может кому-то не понравится какой то функционал и он его втихую переделает? Если кнопки таки поменялись функционалом, то во-первых тест упадет и так, во-вторых если это запланированно было, то корректировки в тест внеслись бы уже заранее. Но в целом я ваш подход понял. Каждый делает как ему вздумается, а потом все собираются и разбираются)