Возник такой вопрос.
Вот получаю я через JS некий элемент:
WebElement downloadMenuItem = Selenide.executeJavaScript(“return $(’.class”)’).find(“a”)[0]");
Однако в чистом селениуме нет метода download.
Хочу кастануть к SelenideElement, но не получается. Как это сделать ?
Вопрос: у селенидовского элемента есть toWebElement(), однако обратной опции нет. Почему ?
Это ведь очень полезная опция и иногда очень нужная.
Почему бы не сделать новый конструктор, который бы брал голый WebElement и на основе его конструировал SelenideElement ?
Выше уже дали правильные ответ, но у меня дополнительный вопрос: а зачем вообще понадобилось искать элемент через JS? Как минимум пример выше аналогичен простому $("a.class").
Да хотя бы тот же джикверевский :contains уже чего стоит.
Потому как в селениде, чтобы сделать что-то подобное, нужно сначала получить коллекцию элементов через $$ и потом отфильтровать по text(), вроде:
так при изменении верстки у вас любые локаторы поедут, я не верю, что вы сможете написать такой локатор, который при переписывании с ангуляра на реакт не сломается
а с поиском по тексту – в xpath можно подпихивать текст в локатор, и не надо будет коллекцию перебирать
Мне кажется xpath покрывает почти все кейсы, я тоже сторонник найти элемент сразу без вложенных FindElements и фильтраций. Хотя поиск джаваскриптом тоже имеет смысл как по мне, неплохая альтернатива xpath, но это тоже будет ломаться при изменении верстки также как xpath, либо вы xpath неправильно готовите
Я знаю один кейс, который не покрывается ни xpath, ни css селектором - это :visible. Это можно только джаваскриптом. Либо $$.filter(visible), что бывает медленно при больших коллекциях.
у селениума такая архитектура, что просятся манипуляции над коллекциями, которые можно было одним запросом делать. Прикольно было бы что то типа linq или streams которые перегонялись бы в js, а потом это одим разом выполнять и получать нужный результат. Думаю для перфоманса это был бы большой буст