Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Для сторінки зі skeleton, product list і payment iframe вибери мінімальні сигнали, після яких користувач може виконати наступну бізнес-дію.
Кожен signal пов’язаний із реальною наступною дією.
Немає sleeps або перевірки кожного DOM element.
iframe control шукається через frame-aware locator.
Locator boundary для елементів усередині iframe; дозволяє далі використовувати role, label та інші locator strategies в потрібному frame.
Що має описувати isLoaded →Пояснює актуальні locators і пошук control усередині iframe.
Що має описувати isLoaded → Першоджерело ↗Заняття охоплює AI-підказки коду, звіти й скріншоти Selenide, fluent interface, Application object та налаштування `Configuration`. Практичний сценарій — відкрити проєкт у Testomat.io, перейти до README, увімкнути редагування, змінити текст у редакторі та зберегти його. Редактор вбудований через `iframe`, тобто містить окремий HTML-документ. Selenium і Selenide не починають автоматично виконувати команди всередині такого документа: як і для нової вкладки або alert, потрібно спочатку перемкнути контекст, а після роботи повернутися до зовнішньої сторінки.
Payment page часто збирається кількома асинхронними етапами: зникає загальний loader, з’являється billing address, потім завантажуються поля платіжного iframe. Формальна поява контейнера ще не означає, що користувач може вводити дані. Тому `isLoaded` повинен чекати саме готових полів або іншого мінімального набору елементів, потрібних наступному кроку сценарію.
Selenide дозволяє перейти у фрейм за індексом, `name`/`id` або знайденим web element. У показаному DOM на сторінці є кілька `iframe`, а потрібний не має зручного `id`, тому індекс відкидається як найкрихкіший варіант. Фрейм знаходиться локатором і передається до `switchTo().frame(...)`. Після перемикання всі наступні команди спрямовуються в HTML-документ фрейму. Кнопки Update і Cancel знаходяться вже на зовнішній сторінці, тому перед кліком викликається повернення до `defaultContent()`. Цей перехід оформлюється всередині методів Page Object, щоб тест не керував технічним контекстом напряму.
Для навігації по camelCase-ідентифікаторах в IntelliJ IDEA вмикається рух курсора за CamelHumps. Це дає змогу переходити й редагувати окремі слова в довгих назвах методів, не виділяючи весь ідентифікатор. Під час першого запуску Selenide не може клікнути на рядок редактора. Через breakpoints, консольний звіт і повторний огляд DOM з'ясовується коренева причина: на сторінці два `iframe`, а локатор вибрав не той. Після уточнення локатора тест переходить у потрібний фрейм і клік виконується; урок підкреслює, що перед зміною методу кліку треба перевірити правильність контексту й фактичний елемент.
Навіть у правильному `iframe` не кожен вузол редактора придатний для введення. Частина DOM позначена як невидима, тому Selenide відхиляє дію як взаємодію з non-interactable element. Потрібно спостерігати, який видимий елемент отримує focus після реального кліку, і шукати саме його, а не прихований технічний вузол. Падіння супроводжується консольним повідомленням, скріншотом і HTML, які використовуються разом для діагностики. Після експериментів урок залишає мінімальну робочу дію для оновлення, а домашнє завдання — змінити текст, натиснути Update і на сторінці README перевірити наявність нового значення. Точне розташування тексту перевіряти не вимагається.