с помощью math.random() подставляю данные до максимальной длины символов

Вот это - просто гениально! 

Простите, не удержалась.

Да, моя ошибка. Но и [swiːt] - это не "свит", а скорее "суит". "в" там все же в любом случае нет, разве что с сильнейшим русским акцентов если.

Test-suite читается как тест свит

Серьезно? По-моему, suite скорее ближе к чему-то среднему между "сут" и "сют" (с коротким звуком похожим на наше "у", вероятно поэтому у нас его и трансформировали в "сьют"), звука "в" там и близко нет.

Вы не знаете, что Вы делаете в тестируемой системе, чтобы залогиниться?

Обычно - ввод логина, ввод пароля, клик по кнопке для авторизации.

Ну, создавайте, раз нужно. В чем проблема? 

Или нужно, чтоб Вам тут готовое решение сразу выдали, а Вам только результат переотправить?

Если помощь нужна - покажите, что уже успели сделать, на чем "споткнулись", какие вопросы возникли и т.д.

А Вы уверены, что у COOKIE Вас правильно инициализированно?

Вроде бы первый параметр - имя (например, "ANID"), потом значение (например, "AHWqTUlyIThXzCDuQ8RXntFTNhBAXHx-jeqdHC12Naifw_ipukQpb2HnCyDmygAL").

У Вас куки в системе так и называются "cookie"? 

Что делать?

Разбираться.

Я бы посмотрела, что будет, если вручную ввести тоже самое. Может быть это само приложение считает дату некорректной и сбрасывает её?

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

 

Да, сталкивалась, решаю именно указанным мною способом.

Как вариант - пройтись дебаггером, чтобы четко отловить, на какой конкретно строчке "падает", почему не попадает в catch (может там не UnhandledAlertException, а какой-то другой эксепшн тест фейлит).

Ещё вариант, сделать catch (Exception e) и там первым делом выводить e.printStackTrace() (самостоятельно выведет в лог) или e.getLocalizedMessage() (просто текст, выводить в лог надо вручную).

Татьяна, большое спасибо!

Проблему решил, вставив закрытие алерта непосредственно перед снятием скриншота.

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

Так я ж написала - текст алерта Вы можете получить и вывести в лог перед тем, как его закрывать. Не будет его на скрине, но зато текст алерта Вы все равно будете в логах видеть.

Да, сталкивалась, решаю именно указанным мною способом.

Как вариант - пройтись дебаггером, чтобы четко отловить, на какой конкретно строчке "падает", почему не попадает в catch (может там не UnhandledAlertException, а какой-то другой эксепшн тест фейлит).

Ещё вариант, сделать catch (Exception e) и там первым делом выводить e.printStackTrace() (самостоятельно выведет в лог) или e.getLocalizedMessage() (просто текст, выводить в лог надо вручную).

Можно в лог выводить текст алерта, а потом закрывать его и фоткать страницу.

((JavascriptExecutor) driver).executeScript("window.scrollTo("+ element.getLocation().x + ", "+ element.getLocation().y + ")");

Ну и дальше уже регулируйте x / y, как Вам нужно.

Например: 

((JavascriptExecutor) driver).executeScript("window.scrollTo("+ (element.getLocation().x + 20) + ", " + (element.getLocation().y + 30) + ")");

У меня с экзекутором вечная беда. Добавил: ((JavascriptExecutor) driver).executeScript("window.scrollTo("+ (element.getLocation().x + 1) + ", " + (element.getLocation().y + 300) + ")");

но элементы не реагируют. 

А как они должны реагировать, по-Вашему?

Это скролл (чтобы Вы могли проскроллить так, как Вам нужно, если не устраивает стандартный скролл, который селениум сам делает.). Это не перенос элементов куда либо. 

Перенос элементов - вообще сомнительная идея. 

Возможно, через JavascriptExecutor. 

В принципе, селениум и так "скроллит" до элементов, которые планирует кликать / заполнять.

driver.switchTo().alert().accept() пробовали?

Сначала фактический (что же произошло в результате указанных шагов), потом ожидаемый (что должно было быть и почему).

Ожидание отрабатывает, т.е. драйвер видит, что элемент появился

until(

ec.presence_of_element_located(locator))

Одно из самых бесполезных и бессмысленных ожиданий, на мой взгляд. 

Нужный элемент может присутствовать в DOM даже, если Вы его не видите.

Также, как и наоборот - может быть не кликабельным, даже если Вы его видите и Вам кажется, что все ок.

Если нужно кликнуть - лучше ждать кликабельности (element_to_be_clickable).

Какая переменная, какой ЯП, куда не передаётся, что вообще вы пытаетесь сделать...

У нас тут напряг с телепатами - лето, отпуска... 

Есть вероятность, что Ваш скрипт просто пытается кликнуть по этому пункту меню ещё до того как этот элемент появится.

Попробуйте вместо простого поиска элемента сделать ожидание кликабельности этого элемента, а уже потом - клик.

У Вас onclick не на инпуте, а на лейбле.

При этом, сама отметка на радиобаттоне тоже ставится этим же onclick'ом (<label for="ID_DELIVERY_ID_41" onclick="BX('ID_DELIVERY_ID_41').checked=true; submitForm();">).

Попробуйте кликать по '#ID_DELIVERY_ID_41+label' (cssLocator).

Либо по '//*[@id='ID_DELIVERY_ID_41']/../label]' (xpath).

Или '//*[@id='ID_DELIVERY_ID_41']/following-sibling::label]' (xpath)

Попробуйте между "cursorOnDestroyButton.moveToElement(destroyList.get(1))" и ".click();" добавить ожидание кликабельности.

Т.е. "переместить курсор", подождать пока кнопка станет кликабельной, кликнуть.

Теоретически, "element present" ждёт появления элементов в DOM'е, а не у Вас на экране. Возможно, блок для результатов в DOM'е присутствует изначально, а после поиска - выводится.

На это намекает "display: none;" в searchResultContainerEmpty - возможно у mCSB_container до поиска тоже стояло "display: none;". Но т.к. сам элемент есть, "wait for element present" его успешно находит.

Если Вы хотите проверять, что элемент не просто есть, но и выведен на экран - есть два варианта:

1. Ждать не "wait for element present", а "wait for element clickable" (не помню уже, как это правильно в Selenium IDE пишется).

2. Если я права и он просто скрыт через style*='display: none;', можно попробовать искать через немного другой локатор. Т.е. ждать не "#searchResult > div.mCSB_container", а "#searchResult > div.mCSB_container:not([style*='display: none;'])" или "#searchResult:not([style*='display: none;']) > div.mCSB_container", в зависимости от того, на какой элемент вешается style*='display: none;' до поиска. Попробуйте посмотреть эту часть кода страницы до "поиска".

 

 

Я про "ручной регресс" не писала вообще, как и про "ручные тесты которые тестируют только видимую часть фичи".

Видимо, мне так и не понять, где и как Вы в моих словах (и в изначальном тезисе, о котором я писала) увидели то, чего там и близко не было. 

а какой ещё регресс бывает который автоматизируют? бывает только ручной регресс который автоматизируют

 

 

 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

вот именно тут вы пишете про ручной регресс

 

И где в этих моих процитированных словах про мифические "ручные тесты которые тестируют только видимую часть фичи"? 

п.с.: те мои тесты, которые я упоминаю, писались "с нуля" на основе документации по соответствующим доработкам + с изучением конкретной реализации вплоть до кода, а не тупо переписывались один в один в автоскрипт из кем-то когда-то написанного "ручного теста". 

Вы опять пишете про "начало". Нужны ли ручные тесты перед автоматизацией, с чего начинать, что надо делать "сразу" и т.д.

Статья (и я тоже) - об автоматизации в целом. 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

Я ничего не писала о том, с чего надо начинать, я не про это вообще пишу.

п.с.: Я работаю в банке и, к сожалению, не могу расписать подробнее, могу лишь сказать, что это весьма далеко от того "списка фич" с пропадающими кейсами, который представили себе Вы. И они не "отсортированы по критичности" - они одинаково критичны, неработоспособность ЛЮБОЙ из этих проверок - блокирующая проблема.

del

 

 

 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

тезис о том, что "ручной регрессионный тест не надо автоматизировать" правилен

 

так как автоматизировать надо "тестирование фич", а не "ручные тесты которые тестируют только видимую часть фичи"

 

Я про "ручной регресс" не писала вообще, как и про "ручные тесты которые тестируют только видимую часть фичи".

Видимо, мне так и не понять, где и как Вы в моих словах (и в изначальном тезисе, о котором я писала) увидели то, чего там и близко не было.