Как кастануть WebElement к SelenideElement чтобы выполнить download ?

Всем привет.

Возник такой вопрос.
Вот получаю я через JS некий элемент:
WebElement downloadMenuItem = Selenide.executeJavaScript(“return $(’.class”)’).find(“a”)[0]");

Однако в чистом селениуме нет метода download.
Хочу кастануть к SelenideElement, но не получается. Как это сделать ?

Вопрос: у селенидовского элемента есть toWebElement(), однако обратной опции нет. Почему ?
Это ведь очень полезная опция и иногда очень нужная.
Почему бы не сделать новый конструктор, который бы брал голый WebElement и на основе его конструировал SelenideElement ?

SelenideElement lll = $(downloadMenuItem);

3 лайка

Вот жеж, даже не заметил ))
Спасибо.

Выше уже дали правильные ответ, но у меня дополнительный вопрос: а зачем вообще понадобилось искать элемент через JS? Как минимум пример выше аналогичен простому $("a.class").

1 лайк

Потому что не ко всему можно добраться через CSS локаторы и где-то нужно юзать jQuery.
jQuery намного богаче в плане поиска по DOM’му.

эм, до чего угодно можно добраться xpath-ом, а чтоб что-то искать пришлось жаваскриптом - такого не припомню вообще

2 лайка

А можете привести конкретные примеры?
Мы просто подумываем подобный функционал запилить в селениде.

xpath-ом ? Серьзено ? :slight_smile:
Чтобы потом при каждом чихе изменения верстки переписывать тесты ?
Нет уж, спасибо.

Да хотя бы тот же джикверевский :contains уже чего стоит.
Потому как в селениде, чтобы сделать что-то подобное, нужно сначала получить коллекцию элементов через $$ и потом отфильтровать по text(), вроде:

$("#search-results a").findBy(text("selenide.org")).click();

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

а с поиском по тексту – в xpath можно подпихивать текст в локатор, и не надо будет коллекцию перебирать

Мне кажется xpath покрывает почти все кейсы, я тоже сторонник найти элемент сразу без вложенных FindElements и фильтраций. Хотя поиск джаваскриптом тоже имеет смысл как по мне, неплохая альтернатива xpath, но это тоже будет ломаться при изменении верстки также как xpath, либо вы xpath неправильно готовите

Я знаю один кейс, который не покрывается ни xpath, ни css селектором - это :visible. Это можно только джаваскриптом. Либо $$.filter(visible), что бывает медленно при больших коллекциях.

1 лайк

у селениума такая архитектура, что просятся манипуляции над коллекциями, которые можно было одним запросом делать. Прикольно было бы что то типа linq или streams которые перегонялись бы в js, а потом это одим разом выполнять и получать нужный результат. Думаю для перфоманса это был бы большой буст

1 лайк