привет, подскажите что я не так делаю http://joxi.ru/bmoNZg1C3PMb8r

@levyarushin Оно, конечно, так, но верно и обратное: часто слишком легко свалить всё на headless, а проблема может быть в другом. Например, какой-нибудь тест может валиться просто потому, что он сам по себе flaky, а в режиме headless он может просто валиться чаще, потому что headless тупо быстрее работает.

Так в том-то и дело что не быстрее.  Вон люди жалуются:
https://bugs.chromium.org/p/chromium/issues/detail?id=948185
https://bugs.chromium.org/p/chromium/issues/detail?id=947936
https://bugs.chromium.org/p/chromium/issues/detail?id=961544
Пока разработчики не нарезвятся, я поостерегусь использовать этот режим.

Да, в целом оно не быстрее работает (или не особо быстрее), но это не значит, что некоторые маленькие кусочки могут работать заметно быстрее. Которые как раз и могут повлиять на тест. Но это так, домыслы.

Ну ладно, остерегайтесь. Дело хозяйское 🙂

так люди и на хром в целом жалуются, вон сколько баг-репортов. что же теперь — совсем им не пользоваться?

"А у вас негров линчуют" (c) :)
Пока headless не соответсвует своему старшему брату, вот подрастет,  тогда будем использовать.
Выигрыша в скорости и ресурсах пока не заметно, а проблем получить можно много.

Если вам повезло и проблем нет - пользуйтесь на здоровье.

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

но я гораздо больше соглашусь с Андреем — с большой вероятностью проблема не в браузере, а в самих тестах. просто проявляется она не при любых условиях

Кмк основное предназначение - рендер веб-страниц для всяких внутренних нужд.

с другой стороны, если именно браузер крешится… тогда надо баг-репорты писать, а не морозиться в надежде, что кто-нибудь другой об этом сообщит

можно попробовать через webworkers сделать, пример блокировка google ссылок возвращается 500:
self.addEventListener('fetch', function (event) {
 if (event.request.url.includes('google')) {
   const header = {
     status: 500,
     statusText: "ERROR",
     headers: { 'Content-Type': 'text/plain' }
   }
   const response = new Response('Internal Google error', header)
   event.respondWith(response)
 }
})

Блокировка google логотипа отвечаем 500-ой ошибкой...
Минус надо обновить еще раз страницу, регистрация воркера занимает время, картинка успевает загрузиться, а после регистрации работает правильно. Регистрация нужна один раз, скрипт serviceWorker работает на всем сайте.

?

привет, подскажите что я не так делаю http://joxi.ru/bmoNZg1C3PMb8r

не совсем про автоматизацию, ближе к управлению процессами и devops. но думаю будет интересно. много букв про Progressive Delivery одной западной игровой компании
-----------
Некоторые вводные
1. Клиент распространяется через огромное кол-во площадок (AppStore, Google Store, Xbox, Micrsofot UWP, наш лаунчер и т.д.)
2. Почти никакие площадки мы не контролируем и изменения доходят до реальных пользователей с разной задержкой (от дней до недель)
3. Если в такой структуре из-за бага что-то будет крашить это означает, что в худшем случае несколько недель игра будет недоступной (падать), что неприемлемо
4. 99.999% контента это UGC (User-generated content) и мы его протестировать с покрытием хотя бы 1% не можем (это миллионы часов нужно играть)
примерные цифры:
    а) миллионы инсталляций на платформе (всех тайтлов)
    б) миллион+ PCCU
5. Количество различного железа и контента настолько большое, что получается невозможно гарантировать покрытие даже на 1% (и при этом нельзя допускать критических багов)
6. Контента который делаем мы внутри не очень много
7. Контент не бандлится с клиентом а хранится в облаке и клиент его скачивает по запросу (т.е. все версионированно и т.д.)

теперь значит как при этом живет фича, кто и как ее делает, немного организационных подробностей

1. фичу делают всегда в ветке (в транк никто комитать не может)
2. перед мержем фичи в транк, нужно попросить бота CI протестировать твою ветку (бот проверит сборку по миллиард платформ и запустит миллиард тестов)
3. обязательное код-ревью минимум 2-х человек на любое изменение (даже однострочное)
4. есть code-ownership, если потрогал код то владелец кода тоже должен быть в ревью (большое изменение может ревьювить 8-12 человек)
5. все изменения должны быть под флагом
  if (myNewFeatureEnabled) {
      новый код
   } else
   {
       старый код
   }
5. если бот тестер и ревьюверы ок, это попадает в транк
6. все флаги по умолчанию выключены

дальше у фичи есть несколько жизненных циклов
1. в разработке в ветке
2. в транке
3. в стейбле
4. на продакшене, но выключена
5. на продакшене, но включена
6. на продакшене и без флага (флаг удален)

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

дальше когда фича доезжает до продакшена (отключенная)
есть глобальное расписание включения фичей (слоты по 15 минут)
разработчик должен зарезервировать себе слот включения своей фичи
включение фичей никогда не пересекается по времени

далее в заданный тайм-слот фичу включают на проде
и разработчик + QA из лайвопс мониторят реалтайм графики
если все ок (10 минут), то фича остается включенной
если не ок, то ее выключают
если будут жалобы от пользователей, служба поддержки умеет сказать список подозреваемых в баге фичей
по времени обращения и т.д.
и тогда если это массовые жалобы то фичу выключают тоже
если жалоб нет и фича включена 4+ недель, то флаг удаляют и фича становится монолитной
т.е. флаги долго не живут

кстати, из за того что мы не контролируем площадки на проде живет большое кол-во версий клиентов одновременно
и иногда прежде чем включать фичу на проде, нужно подождать пока оно везде распространится
флагом реально нужно покрывать любое изменение
например если делаешь большую переделку, то надо физически прямо весь код/классы скопировать и переделывать уже копию
и соответственно от флага создавать либо новый либо старый класс

не выбрана jdk в глобальных настройках jenkis

Выбирал разными способами
http://joxi.ru/n2YEKx9sbvja12

Привет. Кто-нибудь знает, как для WebDriverWait expected_conditions указать путь к вызываемому методу, а не локатороу?

Например, мне нужно указать:
WebDriverWait(driver, 20).until(
expected_conditions.presence_of_element_located(self.app.topnav.logout()))

Но в presence_of_element_located можно передавать только локатор. А у меня локатор указан в методе logout() и мне нужно обратиться к нему. Как быть?