Проблема с организацией скрипта по покупке товаров

webdriver
#1

Нам оно не нужно, но нужен скрипт который покупает товары ( тянет из екселя) на 60+ примерно одинаковых сайтах.

Локаторы уже сам пишу и проверяю через firePath. Иногда правда боль получается (//div[@class=‘shippingbillingforms clearfix’]/////*/input[@id=‘dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription’])

Стоит ли идти на курсы автоматизаторов ?
#2

колосальная боль
если у тебя один такой id “@id=‘dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription’]” на странице
то не пиши всё что до него написал… Просто ищи элемент по id(dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription)

или через @FindBy(id = “dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription”)
или если не юзаешь финд то findElement(By.id(“dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription”)).;

А лучше id и все локаторы держи или в findBy или как строку и передавай как параметр в метод поиска элемента

#3

боль в том что таких id две штуки и путь к ним почти одинаковый и аттрибуты все одинаковые, по этому приходится писать этот ужас что написан выше

#4

и без этой боли можно выкрутиться без проблем

Найди ещё какой-нибудь ближайший локатор на странице к локатору “dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription”

И если писать через css селектор то выйдет: “yourTag.classInTag > #dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription”
Кинь скрин где есть эта id “dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription” я подскажу

#5

пример на селениде

#6

Screen Shot 2016-04-19 at 12.22.17.png1770×899 167 KB

#7

@FindBy(css = "div.cc-personaldetails > input#dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription") public SelenideElement = inputDeliveryAddress;

или же
findElement(By.cssSelector("div.cc-personaldetails > input#dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription"));

#8

Насколько я знаю css селекторы вообще использовать нельзя (мне так говорили)

#9

Кто тебе такую чушь сказал??
Это xpath не оч крут, он в IE кратно медленнее чем css, если через css стабильно находятся элементы во всех браузерах за время до 200 ms, то в IE этот показатель равен 800 ms

1 лайк
#10

Насколько я знаю по конференциям или стятьям на блогах, то xpath говорят что он устаревший костыль

Хотя в нём есть удобные и лаконичные конструкции, но это только единицы по сравнению с css удобствами

1 лайк
#11

А мил человек, а приведи пример CSS локатора с движением назад к корню (якорные). Ну или хотя-бы это преобразуй:
//tr//div[contains(text(), "100000269")]/ancestor::node()[6]//div[contains(text(), "Настройки аккаунта")]/ancestor::node()[4]/td//div[text()="Открытые"]

#13

Движение назад/взять родителя я делаю только через xpath ("…")
ancestor::node()[6] - не знаю что это, - возврат на 6 родственников вверх?

Никогда не было потребности писать столь огромные локаторы, мне проще кастомный элемент создать и с ним бегать

Да и к тому же сказал ведь, что есть удобные и лаконичные конструкции, но это единицы.
Все абсолютно костыли из Xpath мне не нужны, также как и из TestNG по сравнению с Junit

#14

На мой взгляд локатор
//div[@class='shippingbillingforms clearfix']/*/*/*/*/*/input[@id='dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription']
я бы описал так:
//input[@id='dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription']
но если таких несколько, но они фиксированы, то можно указать какой по счету нужен:
(//input[@id='dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription'])[2]
т.е. завернуть локатор в скобки и указать в квадратных скобках какой по счету найденный взять.

#15

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

Но опять же в IE элементы с xpath кратно дольше находятся

#16

Только что проверил вашим способом (//input[@id=‘dwfrm_delivery_singleshipping_shippingAddress_agreeForSubscription’])[2]
Не находит второй элемент

#17

чушь про селекторы

#18

разве их не чаще меняют чем xpath?

#19

Это два разных по своим свойствам и использованию элемента. Юзать нужно и то и другое. Про что что CSS быстрее - согласен, только этого прироста Вы не ощутите так как обычно все дилей связаны с ожиданием выполнения JS или explicit ожиданиях, но душу греет и то хорошо)
PS. Не советую такое ляпнуть на собеседовании, ибо существуют фанатичные люди которые Вас сожгут за такой ответ, но мы то с Вами реалисты и понимаем кто прав. К слову, я из за такого ответа как раз завалил собеседование)
CSS хорош, когда идет прямой поиск элементов. Xpath хорош, когда Вам нужно двигаться по дереву, выше/ниже, итерироваться по элементам (CSS тоже позволяет но не так удобно) внутри DOM дерева - например по ячекам таблицы.

2 лайка