Сообщений в теме: 4

[anton.kolokolcev]

Имеется сайт с небесконечной лентой новостей, оформленной в виде плиточек с картинками, при наведении на каждую из которых показывается более подробная информация (что-то вроде http://nodata.tv/blog).
Я хочу читать и выводить эту информацию для каждого квадратика. Траектория обхода такая: двигаемся в центр первого квадрата-картинки -> читаем дату -> читаем тэги -> читаем Artist / Album [Year] -> центр второго квадратика и т.д. Для обхода использую new Actions(driver).moveToElement(element).perform(); А проблема собственно в следующем: такой тест проходит 1 раз из 10, то курсор переклинит и он окажется где-то явно не там, где нужно, то не вся информация считается. Поэтому хочется разобраться в следующем:
1) что происходит сразу после вызова .perform()? Допустим, реальный указатель находится в заголовке окна браузера (я его специально туда завожу, чтобы не мешался на странице, правда не знаю, влияет ли это на что-нибудь), я вызываю moveToElement и perform. Где после этого действия оказывается указатель? Он мгновенно возвращается на свое реальное место или как-то запоминается на последнем элементе?
2) имеет значение, виден ли полностью элемент на странице, например, если одна строка находится в самом низу экрана, а другая уже за ним (у меня с начала из-за этого падал тест, и я насильно стал делать moveToElement к строке с датой вдобавок к moveToElement к центру картинки)?
3) какой самый надежный способ работы с такими hover элементами?
Вот вроде бы и все, что меня пока гложит. Любая помощь, как грится, будет вэри апрешиэйтыд.

[owasp]

1) Указатель оказывается в том месте, куда он был помещён. На своё реальное место указатель не возвращается.
2) Имеет значение. Чтобы навести указатель на элемент, который может быть в конце страницы (быть не видимым) можно пробовать отображать его, используя скроллинг.
Например, в C# это делается при получении значения свойства LocationOnScreenOnceScrolledIntoView см. http://selenium.goog...ledIntoView.htm

var fakePoint = (iwebElement as Locatable).LocationOnScreenOnceScrolledIntoView;
var fakePoint = (iwebElement as RemoteWebElement).LocationOnScreenOnceScrolledIntoView;

В Java есть аналогичный get-метод

getLocationOnScreenOnceScrolledIntoView()

, см. http://selenium.goog...rolledIntoView()
3) Особо с hover-элементами не работал, но понятно, что при работе с ними можно:
3.1. использовать поиск относительно базового элемента, на котором сейчас фокус, а не относительно страницы браузера. Так как поиск относительно браузера даст ложные срабатыввания (если не фильтровать по видимости) и будет выполняться дольше.
3.2. не использовать кеширование элементов (каждый раз искать элементы по новой), так как наличие hover-элемента на странице непостоянное.

[anton.kolokolcev]

Спасибо за советы!
2) поменял new Actions(driver).moveToElement(element).perform(); на mouse.mouseMove(element.getCoordinates());
Разницу между getLocationOnScreenOnceScrolledIntoView() и mouseMove(element.getCoordinates()) не сильно понял, но так первый deprecated, то решил использовать второй способ.

3.1. использовать поиск относительно базового элемента, на котором сейчас фокус, а не относительно страницы браузера. Так как поиск относительно браузера даст ложные срабатыввания (если не фильтровать по видимости) и будет выполняться дольше.

Что вы в данном случае имеете в виду под поиском? Я везде использую xpath с номером нужного мне контейнера: xpath("//div[@class='column-13'][" +postNumber+ "]
Если использовать xpath с абсолютными путями, то могут появиться ложные срабатывания?

[owasp]

Если использовать xpath с абсолютными путями, то могут появиться ложные срабатывания?

Нет ложных срабатываний не будет. Просто появляется дублирование кода - для всплывающего элемента нужно повторять в селекторе селектор родительского элемента (так как обычно, у всплывающих элементов нет своего уникального идентификатора в рамках всей страницы). Если не считате дублирование текста селекторов важным, то никаких проблем нет.

При изменении дизайна, придётся не один раз изменить селектор для основного элемента, а изменить его несколько раз - дополнительно поправив селекторы дочерних элементов.

В моём проекте есть строки таблицы (которые могу уникально определить), а внутри строк есть всплывающие элементы - кнопки действий, что появляются для каждой строки при наведении. И у кнопок своих уникальных селекторов нет.
Единственный вариант уникального селектора для всплывающего элемента, заданный относительно браузера - "Уникальный селектор основной строки" + "селектор всплывающего элемента".
Но можно, ведь, получить основную строку по селектору "Уникальный селектор основной строки", а уже относительно полученного IWebElement получить дочерние элементы по коротким относительным селекторам "селектор всплывающего элемента".

Если использовать Java и базовый паттерн PageObject, то задавать относительные селекторы в атрибутах нельзя - все селекторы задаются относительно браузера => приходится дублировать селекторы.
Если использовать чистый PageObject, то работу со всплывающими элементами без дублирования селекторов можно организовать передавая в методы работы с ними базовый для них IWebElement (а относительно него искать).

Можно использовать паттерн HTML Elements, который реализован в разработке Яндекса, тогда исключается дублирование кода и дублирование селекторов:
http://habrahabr.ru/...ex/blog/158787/
https://github.com/y...ls/htmlelements

В своих тестах использую C#. Идеи HTML Elements повторил, как сумел, средствами dotNet. Получилось сыровато (есть проблема, когда компонент вложен в компонент, вложен в компонент и все эти элементы не являются кешируемыми - конечные узлы ищутся долго), но работает. Думаю сделать механизм обновления дерева компонент (Refresh()), как это сделано в TestComplete и разрешить каждому компоненту кешировать экземпляр своего родительского компонента. Это немного увеличит затраты по памяти (16 байт на ссылку), но увеличит быстродействие.

[anton.kolokolcev]

Спасибо за ссылки. Узнал много нового. Попробую использовать html elements (пишу на java), уж больно наглядные тесты с ними получаются.
Про кешируемость вообще не знал, вряд ли это сильно скажется на быстродействии моих поделок, но на будущее фича пригодится.