Привет! Есть ли в селениде сейчас возможность использовать thread-safe конфиги? Нашел старый исус selenide/selenide#252 но он похоже так и не был решен.
Но нечто подобное реализовали в версии 5.0.0: https://ru.selenide.org/2018/10/10/selenide-5.0.0/
У нас похоже не здоровая ситуация значит :). Пишем тесты на апиум под iOS, появилась необходимость их паралелить. паралельность достигается за счёт запуска на разных симуляторах, для этого апиуму нужно отправлять разные капабилити.
если запускать драйвер рекомендуемым способом:
Configuration.browserCapabilities = desiredCapabilities;
Configuration.browser = IOSProvider.class.getName();то тогда первые тесты все ломятся на один симулятор и падают.
Потому, что сейчас нужно писать костыли, в виде $("someCss").getWrappedElement().toString() и дальше парсить
я без понятия как показать, скрины вряд ли с проекта кидать буду
Но не понимаю - нафига такие сложности?
предлагаешь создавать заново тучу объектов, вместо того что бы перезагрузить элемент? так ведь перформанс просидает
попробую объяснить, есть например GiftPageComponent принимающий giftItem в конструкторе, в GiftPageComponent методы аля getTitle() { giftItem.$("...") } и т.д., собираеться коллекция из GiftPageComponent-ов, мы чегото меняем, перезагружаем страницу или блок, ловим StaleReference, обрабатываем AOP, перезагружаем элемент. Что бы все работало нужно создавать и хранить какой то индетификатор по которому найду и перезагружу giftItem, когда мог бы просто сделать giftItem = $(giftItem.getWrappedLocator());
можете сделать пример кода, хотя бы который даже не падает? я примерно понял что вы хотите, но я не понимаю как должно помочь
giftItem = $(giftItem.getWrappedLocator()); - какая разница какой там элемент, перепоиск элемента сработать должен и без переприсваивания ссылки на новый элемент
я к тому что
1)
и
2)
это не одно и тоже.
в первом случае, да всегда будет
во втором element.$("") должен перенайти элемент и не падать с
1)
element = driver.findElement("")и
2)
element = $("")это не одно и тоже.
в первом случае, да всегда будет
StaleReference на попытку element.findElement() при перезагружаем страницу или блокво втором element.$("") должен перенайти элемент и не падать с
StaleReference
и да, сразу скажу, селенид последней версии
Всем привет. Не знаю, может уже предлагалось ранее, но хочу предложить.
А не пора ли в селениде запилить универсальный метод локации элемента?
Ну то есть, что можно было делать $("some css locator") и тем же методом $("some xpath locator").
Предпослыка - в chrome devtools например, во вкладке Elements, поиск работает как раз одинаково, независимо от типа локатора (думаю под капотом он там как-то определяет тип локатора)
По факту, такое можно сделать и в селениде - вопрос - нужно ли?
А не пора ли в селениде запилить универсальный метод локации элемента?
Ну то есть, что можно было делать $("some css locator") и тем же методом $("some xpath locator").
Предпослыка - в chrome devtools например, во вкладке Elements, поиск работает как раз одинаково, независимо от типа локатора (думаю под капотом он там как-то определяет тип локатора)
По факту, такое можно сделать и в селениде - вопрос - нужно ли?
По идее можно было бы запилить, если по строке всегда можно однозначно определить, это css или xpath. Я слышал, что когда-то в Thucidydes была такая фича, и с ней были проблемы: иногда он неправильно определял. Но сам я этот вопрос детально не изучал.
Однажды мне скинули для примера код, который вроде как умеет определять, CSS или Xpath:
sergueik/selector_validators@479f35a
sergueik/selector_validators@479f35a
Как раз у меня был открыт пример с Serenity (aka Thucidydes), и там они проверяют по локатору - это xpath или нет, и потом дёргают соответствующий find метод
определяют через javax.xml.xpath.XPathFactory
не знаю, насколько стабильно она будет отличать css от xpath-a
wdio кушает в $/$$ любой селектор без явного указания что это ( а потом транслирует всё в xpath )
ну вот да, тут тож есть варианты - как это реализовать - либо всё в xpath транслировать, либо как я описал - определять тип локатора и вызывать соответствующий метод. Как по мне - транслировать всё в xpath - это overhead
@dimkin-eu Нет, зачем транслировать. Если это xpath - искать по xpath, а если это css - искать по css.
И остаётся вопрос, не существует ли такой строки, которая была бы одновременно и валидным CSS, и валидным XPath.