.text() .getText() ?

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

Вот ковыряюсь, никак не могу нагуглить, как именно тайтл взять и потом в sendKeys эту инфу вывести.
Если кто-то может помочь, очень благодарен 🙏🏼

И за qaru.site тоже

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

Помню в начале 2000, когда irc чаты были очень распространены,  местные опы тоже любили такие красивые фразочки "я дарю вам целые сутки" и прочее )
Прям молодость вспомнил

ирка и сейчас живёт

Всем привет) подскажите пожалуйста, как корректно сохранять значения с теста в одном классе и передавать его в другой?) testng+java

привет. никак. между тестовыми классами и тестовыми методами корректно ничего не шарить.
если нужны прекондишены - то выполять их корректно в before class/before method, и юзать уже в куче других тестов. но не менять значения от теста к тесту.

не совсем про автоматизацию, ближе к управлению процессами и 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+ недель, то флаг удаляют и фича становится монолитной
т.е. флаги долго не живут

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