Пошук · Мануфактура

Python мануфактура Java Design Patterns для автоматизаторів

Java · Основний курс · 2:40–6:30

Перенесення Selenide-тесту на чистий Selenium

Проєкт розділяється на окремі пакети для Selenide і Selenium, після чого той самий сценарій переписується через `driver.findElement(...)`, `By.cssSelector(...)`, `sendKeys(...)` і `click()`. Для текстового локатора, якому немає прямого аналога `By.text`, використовується XPath. Механічна заміна Selenide-викликів допомагає швидко отримати початковий варіант, але залишає багатослівний код і не додає очікувань. Тому наступний крок — явно визначити, коли елемент готовий до пошуку, перевірки або дії.

Selenium: очікування та мікрообгортки →

Java · Основний курс · 1:14:30–1:19:30

Очікування перед `click` і `sendKeys`

Перед `click()` і `sendKeys(...)` wrapper викликає visibility wait для збереженого `By`, а потім виконує дію. Окремо пояснюється різниця між visible і enabled: видимий елемент має координати та розмір, але браузер усе ще може вважати його непридатним до взаємодії. Selenium представляє знайдений вузол через element id, який WebDriver використовує в наступних командах. Якщо DOM замінить вузол між перевіркою стану та дією, посилання може застаріти; саме цей проміжок пояснює частину нестабільних `StaleElementReferenceException`.

Selenium: очікування та мікрообгортки →

Java · Основний курс · 34:30–42:30

Розділення пошуку, дій і очікувань

Обгортка розділяється на вузькі частини: пошук елементів, операції над ними та waits. Один великий helper із усіма кліками, селекторами й очікуваннями складніше читати, змінювати та паралельно редагувати без merge conflicts. Початкова форма `new ElementActions().click(driver.findElement(...))` читається у зворотному до наміру порядку. API перебудовується так, щоб сценарій спочатку знаходив ціль, а потім викликав дію над результатом. `ElementActions` інкапсулює цільовий елемент і надає `click()` та `sendKeys(...)`, завдяки чому тест ближчий до послідовності користувацьких дій.

Selenium: очікування та мікрообгортки →

Java · Основний курс · 55:30–1:03:55

Основні параметри Selenide Configuration

`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-режиму.

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

Запитати в чаті про «sendKeys» →