посмотрите на облачных вендоров — казалось бы, зачем они тратят силы и время на предоставление возможности запускать "устаревшие" браузеры? однако они это делают. значит, это пользуется достаточным спросом, чтобы окупать затраты

у Фаерфокса есть LTS / ESR версия, которая выходит раз в год. не оно?

конечно, обычно ESR прибивают гвоздями

на опасный путь встаете)) а какую задачу хотите этим решить? и какие именно тесты?

достаточно сделать так чтобы после упавших тестов код возврата был ноль, в команду запуска тестов можно добавить в конце || exit 0

Допустимый процент упавших🤔😱

вот да, явно не бест практикс) а если нужно билд выкатить/сохранить или еще что - как вариант рецепт выше

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

как по мне тесты ради зеленых отчетиков это профанация, и тут надо разьеснять менеджменту идти что почем и в чем вообще смысл тестов) но это субъективное мнение

вы случаем не прожект менеджер ?

WebDriverWait и ThreadLocal-переменные

Думаю, многие знают, что WebDriver предоставляет два механизма ожиданий — неявные и явные.

При использовании неявных ожиданий функции поиска элементов (findElement и findElements) не возвращают результат до тех пор, пока не найдутся нужные элементы, либо пока не истечёт установленный таймаут. Это ожидание реализовано на стороне браузера, поэтому WebDriver никак не может его прервать, ему остаётся только ждать либо положительного, либо отрицательного результата поиска.

Явные ожидания реализуются при помощи класса WebDriverWait, в который можно передать некоторую функцию-условие. Эта функция будет периодически вызываться до тех пор, пока либо не вернётся "хороший" результат, либо не истечёт время, в течение которого должно проверяться условие.

А что будет, если использовать оба механизма ожидания одновременно, при этом установить время неявного ожидания, скажем, на 5 минут, а потом использовать явное ожидание условия "findElements возвращает непустой список элементов" и указать в нём время ожидания 1 минута?

Оказывается, неявные ожидания побеждают явные. Так как функция findElement заблокируется на 5 минут, класс WebDriverWait не сможет завершить работу через 1 минуту, он будет честно ждать 5 минут, пока функция findElement не вернёт результат. Потому что WebDriverWait вызывает проверяемое условие в текущем потоке, тем самым блокируя его.

А что если функция-условие вообще заблокируется навсегда и не вернёт никакой результат? Тогда и WebDriverWait тоже зависнет навсегда.

Примерно год назад нам пришёл пулл-реквест, который решал эту проблему:
https://github.com/SeleniumHQ/selenium/pull/7692

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

И всё было бы хорошо, но после выпуска версии 4.0-alpha-5 с этим улучшенным механизмом ожиданий мы получили целую серию баг-репортов, в которых сообщалось, что явные ожидания перестали работать вообще!

Оказывается, многие люди хранят ссылку на драйвер в виде ThreadLocal-переменной, то есть с каждым потоком ассоциируется свой экземпляр драйвера. Это делается якобы для того, чтобы тесты было проще распараллеливать. И если такая ThreadLocal-переменная используется для получения ссылки на драйвер в условии ожидания, а условие проверяется в отдельном потоке — оно не может получить доступ к драйверу!

Вообще-то драйвер передаётся в условие в виде параметра, так что обращаться к ThreadLocal-переменной не нужно вообще. Тот факт, что люди этот параметр игнорируют и вместо этого достают ссылку на драйвер из  ThreadLocal-переменной, оказался для нас сюрпризом. Это же явный признак плохого дизайна тестов именно с точки зрения их распараллеливания!

Но... Спустя несколько месяцев и кучку баг-репортов мы решили это изменение откатить и вернуться к старой блокирующейся реализации. Обратная совместимость важнее.

Возможно, в будущем рядом с классом WebDriverWait появится похожий на него класс WebDriverWaitAsync, который будет проверять условия в отдельном потоке. А пока признаем, что любители ThreadLocal-переменных победили.

Да, явно не бест практис
все ж знают что нужно использовать правильные инструменты
https://github.com/auchenberg/volkswagen

Проорал с тредлокала

к сожалению, некоторые инструменты (включая популярный в местных кругах selenide) сильно на это завязаны...

проорал дважды. Изоляция объекта в потоке джавы, главный бонус которой - многопоточность.  100 джава коров из 100

Всем привет, такая проблема: в тесте (selenium на python) нужно сделать скрины веб-версии сайта на мобильном устройстве, не просто видимой области, а всего вниз по скролу.

Проблема потому что: девайсы виртуальные на browserstack (не responsive mode в chrome), а значит: resize window и изменение масштаба не сработает (для моб. не поддерживается браузерстаком) скрин веб-элемента <body> не сработает (для моб. не поддерживается браузерстаком), скрин видимой части + скрол + скрин следующей части + склейка картинки тоже не сработает как хочется, т.к. в скрине будет адресная строка и кусок интерфейса мобильного устройства, и это все появится еще раз на месте склейки со вторым (3м,4м и тд.) скрином, убрать интерфейс не получится т.к. headless mode в моб. не поддерживается.

Готовые библиотеки скриншот-тейкеры с возможностью захвата полной страницы написаны для десктопа. Какие есть варианты (если они вообще есть)?

ашот разве не делает скрин всей страницы?

Всем привет, есть ли чатик по автоматизации мобилок?

не только по автоматизации: https://t.me/MobileNinjas

Спасибо