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

[Distortion]

Столкнулся с такой проблемой:

 

Элемент, до которого хочу достучаться, находится внизу экрана. Достучаться надо кликом, поэтому я не парился при написании теста (thay say, selenium скроллит до нужного элемента, когда зовёшь у него click).

Однако, в зависимости от фазы Луны и текущего положения в эклиптике, то страница скроллится, а то мы падем с ошибкой "element not visible".

 

Разумеется, первое, что подумал - что-то не успевает прогрузиться и надо подождать.

Юзал всяческие wait.until в различных вариантах и комбинациях, выставлял sleep, писал циклы, внутри которых получал новый экземпляр элемента и в try..catch пытался на него нажать... но всё пофиг: если клик не прошёл сразу, то никакие ожидания не помогут (для верности как-то суммарно прождал аж 10 минут).

 

Начал дебажить.

 

По свойствам - is_enabled = True, is_displayed - False, но такая фигня даже и перед тем, когда клик срабатывает успешно (т.е. это никак не мешает клику отскроллить страницу до состояния элемента is_displayed = True).

Начал смотреть как меняются другие свойства, и обнаружил, что когда клик проходит успешно, у меня вполне адекватные значения у свойств "size", "location" и "location_once_scrolled_into_view", а когда клика нет, то всё по нулям.

 

На этом я впал в ступор...

Начал придумывать воркэраунды, подумал, что если селениум не может отскроллится (а скорей, он тупо не понимает куда надо отскроллится, раз позиция контрола - 0, 0), но надо отскроллить страницу самому...

 

А вот тут тоже беда: никакими выгугленными средствами отскроллить страницу не получилось. Не помогают никакие driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")...

 

Жду дельные советы, а также бесполезные и/или злорадские комменты.

 

Инвайронмент:

Ubuntu 12.04.4

Selenium 2.53.4

ChromeDriver 2.15.322448

Chrome 49.0.2623.87

Python 3.5.1

Py.test 2.9.2

[TatyanaV]

Код не мой, нашла где-то на просторах интернета. Но у меня такой вариант работает.

Вариант для Java, но и для Питона почти наверняка этот вариант есть.

    import org.openqa.selenium.interactions.internal.Coordinates;

    public void scrollToElement(WebElement element) {
        try {
            Coordinates coordinate = ((Locatable) element).getCoordinates();
            coordinate.onPage();
            coordinate.inViewPort();
        }
        catch (NoSuchElementException ignore) {}
        catch (ElementNotVisibleException ignore) {}
    }

P.S.: Акс?

[BabyRoot]

А что такой хромдрайвер старый?

Обновите его.

[user12]

Это питон, а не джава

 

и ошибка "element not visible"

[TatyanaV]

Это питон, а не джава

 

и ошибка "element not visible"

И что? Видя вариант на Джаве очень сложно проверить, нельзя ли это же решение реализовать на Питоне?

У меня была проблема, аналогичная указанной в первом посте - мне удалось её решить так.

[DmitriyQA]

Если уж так все сложно, то сделайте уже это выполнение джаваскрипта.  JS легко это выполнит. Хотя я этим не пользуюсь мы в фреймворке написали метод scrollIntoView, он прокрутчивает к конкретному эелементу. А так вот вам:

 

WebDriver driver = new AnyDriverYouWant();
if (driver instanceof JavascriptExecutor) {
((JavascriptExecutor)driver).executeScript("yourScript();");
} else {
throw new IllegalStateException("This driver does not support JavaScript!");
}

 

И собсвтенно скрипт для прокрутки 

 

window.scrollTo(0,document.body.scrollHeight);

 

или

 

executeScript("arguments[0].scrollIntoView();");

[DennisM]

Были такие грабли. Скроллится отлично этим:

 

import org.openqa.selenium.interactions.Actions;

 

***

 

Actions mouse = new Actions(driver);

mouse.moveToElement(driver.findElement(element_locator)).build().perform();  

[Distortion]

 

Это питон, а не джава

 

и ошибка "element not visible"

И что? Видя вариант на Джаве очень сложно проверить, нельзя ли это же решение реализовать на Питоне?

У меня была проблема, аналогичная указанной в первом посте - мне удалось её решить так.

 

 

Не, у селениума на джаве и пайтоне слишком разные фреймфорки, многих аналогов тупо нет :)

 

P.S.: Акс?

 

Йес, ай эм. Цири, узнал тебя))

[Distortion]

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

 

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

 

Дело было вот в чём:

1. Абсолютно все элементы веб-морды грузились СРАЗУ, просто бОльшая часть из них - скрыты

2. На весь экран разворачивался контейнер, внутри которого хранились все виджеты, внутри которых в свою очередь - элементы

3. Внутри контейнера отображается видимый виджет

4. Контейнер сам по себе не уходит за видимые границы документа, поэтому скроллить документ бесполезно и бессмысленно

5. Внутри разных контейнеров располагались элементы с одинаковыми ID, что печалит w3c (поэтому-то иногда и find'ом и находился элемент с нулевыми параметрами - мы находили тупо элемент на другом, невидимом виджете)

 

Как победил:

1. Во фреймворке обернул все действия с элементами во враппер: создал класс для элементов с кучей свойств и методов, зовущихся у Driver или WebElement

2. В классе стреницы при инициализации мы получаем WebElement виджета

3. Поиск элементов внутри страницы мы ведем через враппер и не от Driver'а, а от WebElement'a виджета (или от Driver'a, когда это необходимо)

4. Перед воздействием на элемент через ActionChains выполняем move_to_element, что скроллит не страницу, а виджет

5...

6. PROFIT

[DmitriyQA]

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

 

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

 

Дело было вот в чём:

1. Абсолютно все элементы веб-морды грузились СРАЗУ, просто бОльшая часть из них - скрыты

2. На весь экран разворачивался контейнер, внутри которого хранились все виджеты, внутри которых в свою очередь - элементы

3. Внутри контейнера отображается видимый виджет

4. Контейнер сам по себе не уходит за видимые границы документа, поэтому скроллить документ бесполезно и бессмысленно

5. Внутри разных контейнеров располагались элементы с одинаковыми ID, что печалит w3c (поэтому-то иногда и find'ом и находился элемент с нулевыми параметрами - мы находили тупо элемент на другом, невидимом виджете)

 

Как победил:

1. Во фреймворке обернул все действия с элементами во враппер: создал класс для элементов с кучей свойств и методов, зовущихся у Driver или WebElement

2. К классе стреницы при инициализации мы получаем WebElement виджета

3. Поиск элементов внутри страницы мы ведем через враппер и не от Driver'а, а от WebElement'a виджета (или от Driver'a, когда это необходимо)

4. Перед воздействием на элемент через ActionChains выполняем move_to_element, что скроллит не страницу, а виджет

5...

6. PROFIT

Ну обычно все люди и делат врапперы, даже не зависимо от вложенноти елементов. Правила муветона так сказать

[TatyanaV]

Я такие штуки обычно стараюсь победить локаторами.

Т.е. ковыряюсь пока не удастся найти приемлимый и однозначный локатор, по которому находится только один видимый и доступный элемент.  

Иногда это весьма не просто, что очень не хорошо :(. 

Единственный вариант - вот такие обходные пути и/или договариваться с разработчиками.

[TatyanaV]

Ну обычно все люди и делат врапперы, даже не зависимо от вложенноти елементов. Правила муветона так сказать

Отнюдь не все. И далеко не всегда это вообще имеет смысл.

[Distortion]

Я такие штуки обычно стараюсь победить локаторами.

Т.е. ковыряюсь пока не удастся найти приемлимый и однозначный локатор, по которому находится только один видимый и доступный элемент.  

Иногда это весьма не просто, что очень не хорошо :(. 

Единственный вариант - вот такие обходные пути и/или договариваться с разработчиками.

 

Писать длиннющие CSS-селекторы или X-пути - это не выход. Захотят завтра разрабы ещё в один контейнер виджет убрать - и всё сразу станет падать, сиди и переписывай все локаторы... А так - только один локатор виджета подправил, и всё (да и не факт, что вообще придётся что-то править)

 

В моём случае нет смысла ковыряться во всём дереве, если нужный элемент 100% является чилдом у виджета.

[TatyanaV]

 

Я такие штуки обычно стараюсь победить локаторами.

Т.е. ковыряюсь пока не удастся найти приемлимый и однозначный локатор, по которому находится только один видимый и доступный элемент.  

Иногда это весьма не просто, что очень не хорошо :(. 

Единственный вариант - вот такие обходные пути и/или договариваться с разработчиками.

 

Писать длиннющие CSS-селекторы или X-пути - это не выход. Захотят завтра разрабы ещё в один контейнер виджет убрать - и всё сразу станет падать, сиди и переписывай все локаторы... А так - только один локатор виджета подправил, и всё (да и не факт, что вообще придётся что-то править)

 

В моём случае нет смысла ковыряться во всём дереве, если нужный элемент 100% является чилдом у виджета.

 

Я не говорила "длиннющие" :) "Приемлимый" - для меня это как раз и есть локатор, не ломающийся при смене структуры, но при этом настолько короткий, насколько это в принципе возможно.

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

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

 

Может быть и правда стоит мне попробовать врапперы. 

Сейчас у меня только один такой доп.класс для уж очень гемморойных элементов.

[elvis]

Я по-разному подхожу к таким сценариям. Иногда нахожу уникальный xpath или css локатор, а иногда делаю отдельный класс на нужный компонент с соответствующими хелперами. Каждый случай уникален