Selenide: iframe, fluent interface та конфігурація

Заняття охоплює AI-підказки коду, звіти й скріншоти Selenide, fluent interface, Application object та налаштування Configuration. Практичний сценарій — відкрити проєкт у Testomat.io, перейти до README, увімкнути редагування, змінити текст у редакторі та зберегти його.

Редактор вбудований через iframe, тобто містить окремий HTML-документ. Selenium і Selenide не починають автоматично виконувати команди всередині такого документа: як і для нової вкладки або alert, потрібно спочатку перемкнути контекст, а після роботи повернутися до зовнішньої сторінки.

В IntelliJ IDEA вмикається Full Line completion для Java. На відміну від звичайного completion, яке пропонує проіндексовані класи, методи й доступні члени об'єктів, Full Line completion намагається запропонувати цілий рядок на основі контексту коду. Викладач описує цю модель як локальну й радить спочатку попрацювати саме з нею.

GitHub Copilot може запропонувати кілька рядків, метод або клас, але така генерація не гарантує коректності. Для повторюваних Page Objects і тестових дій підказки можуть бути доречними, проте кожну пропозицію потрібно читати й перевіряти. У відео також наголошено на відмінності між локальною моделлю та передаванням контексту сторонньому сервісу.

До тестового запуску підключається розширення текстового звіту Selenide. Воно виводить у консоль таблицю дій, їхній статус і час виконання; для поточної навчальної задачі такого звіту достатньо, щоб бачити, на якій команді зупинився тест і скільки вона тривала.

Selenide також може зберігати скріншот і HTML сторінки після помилки. Ці артефакти доповнюють консольний звіт: скріншот показує видимий стан, а HTML допомагає перевірити фактичну структуру й атрибути елементів.

Під час написання нового тесту Full Line completion пропонує продовження на основі наявного проєкту. Викладач радить залишити стандартні налаштування, користуватися запропонованим shortcut і за потреби приймати лише відповідну частину підказки, а не весь рядок.

Щоб будувати виклики через крапку, метод Page Object замість void повертає поточний тип і завершується return this. Так open() може повернути SignInPage, після чого одразу викликається loginUser(...). У відео цей стиль пов'язують із назвами fluent interface та chain of invocation; у заголовку уроку також використано Chain of responsibility.

Повернення this зручне для послідовності дій у межах одного Page Object. Повертати з кожного методу наступну сторінку викладач не радить: довгі ланцюжки приховують переходи й ускладнюють code review. Допустимий локальний виняток — компонент або popup, який належить поточній сторінці й природно стає наступним об'єктом взаємодії.

Спільні значення, потрібні кільком тестам, переносяться до наявного BaseTest, а не дублюються. Для них обирається найвужча достатня видимість, у прикладі — protected для класів-нащадків.

Повторюваний login переноситься до BaseTest, після чого тест починається з уже відкритої сторінки проєктів. Запуск підтверджує успішну авторизацію, а консольний звіт показує пройдену перевірку shouldBe(visible) та її тривалість у мілісекундах.

Коли fluent interface утворює довгий вираз, кожну логічну дію варто переносити на окремий рядок. Це не змінює виконання, але дозволяє читати сценарій зверху вниз і швидше співвідносити падіння зі звітом.

Сценарій розділяється між ProjectsPage, сторінкою окремого проєкту та ReadmePage. Для переходів використовуються посилання README й кнопка Edit; якщо немає стабільнішого атрибута, елемент у демонстрації шукається за видимим текстом.

Текстовий локатор прийнятний для продукту з однією стабільною мовою, але стає крихким, коли копірайт часто змінюється або UI має кілька локалізацій. Після перемикання мови такі тести масово падають. Автоматизацію повної перевірки локалізацій викладач не рекомендує як першу задачу для початківця: спершу потрібно зрозуміти DOM і стабільні контракти конкретного продукту.

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 перевірити наявність нового значення. Точне розташування тексту перевіряти не вимагається.

Коли BaseTest починає відповідати за login, конфігурацію та ініціалізацію всіх Page Objects, він перетворюється на надто широкий контейнер. Ініціалізація сторінок переноситься до окремого Application, а тест отримує один об'єкт app і звертається через нього до потрібної сторінки.

У відео цей підхід порівнюється з агрегатором або facade і застерігається, що глобальний God Object погано масштабується на дуже великі паралельні набори тестів. Для невеликого навчального проєкту Application object спрощує сценарії. Якщо система має окремі домени, наприклад сайт і адмінку, їх можна розділити на WebsiteApplication та AdminApplication замість одного безмежного контейнера.

Configuration містить багато параметрів, але для старту потрібні лише ті, що відповідають реальному середовищу. Assertion mode може дозволити soft assertions: окремі перевірки фіксують помилки, але тест доходить до кінця й лише тоді показує сукупний результат. headless приховує вікно браузера; у віддалених запусках такий режим є типовим.

Розмір браузера радять ставити не довільно, а на мінімальну підтримувану продуктом ширину, бо саме там частіше проявляються проблеми компонування. Глобальний JavaScript click може трохи прискорити тести або обійти окрему проблему кліку, але його не слід вмикати всюди: він відрізняється від звичайної взаємодії й може зробити сценарій занадто швидким для застосунку. Для одиничного проблемного елемента краще обрати JavaScript лише в параметрах конкретного кліку.

Швидке встановлення значення через JavaScript вставляє текст цілком. sendKeys або append потрібні, коли важливе посимвольне введення й виклик change/autocomplete-поведінки. Для завантажень Selenide має кілька режимів, а download folder варто розташувати в build для Gradle або target для Maven, щоб артефакти не потрапляли до репозиторію.

pollingInterval визначає паузу між повторними перевірками умов на кшталт shouldBe(visible); у прикладі стандартне значення — 200 мс. Зменшувати його слід лише після вимірювання: локально тест може прискоритися, але в Jenkins, BrowserStack або хмарних середовищах кожна перевірка має мережеву затримку між регіонами. Наприкінці викладач зводить мінімальну конфігурацію до baseUrl і обґрунтованого вибору headless-режиму.