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

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

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

Чому implicit wait не підходить динамічним сторінкам

В уроці радять не змішувати implicit і explicit waits та для динамічних React/Angular-сторінок покладатися на explicit waits. Implicit wait очікує, доки елемент з'явиться в DOM під час `findElement`, але сама наявність вузла ще не означає, що він видимий, enabled або придатний до взаємодії. Після пошуку Selenium працює з ідентифікатором конкретного елемента. Якщо сторінка перерендерила вузол, старе посилання більше не відповідає поточному DOM і команда може завершитися `StaleElementReferenceException`. Explicit wait через `WebDriverWait.until(...)` і `ExpectedConditions` дозволяє чекати саме потрібного стану, наприклад видимості або очікуваного тексту.

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

Java · Основний курс · 1:00:50–1:06:30

API очікувань для visibility, invisibility і text

У класі waits додаються методи для очікування видимості, невидимості та тексту. Негативну умову можна виразити через `not(...)`, а готові комбінації також доступні через `and(...)` та `or(...)`. Перед вибором методу відкривається реалізація `ExpectedConditions`, щоб перевірити, чи він приймає `By` або `WebElement` і яку саме умову оцінює. `ElementActions.waitFor()` повертає об'єкт waits для поточної цілі. Це дозволяє будувати виклики на кшталт `find(...).waitFor().visibility()` або очікувати потрібний текст, не розміщуючи `WebDriverWait` безпосередньо в тесті.

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

Java · Основний курс · 0:00–6:48

WebDriver і двостороння модель Playwright

Selenium виконує команди через WebDriver: тест звертається до драйвера HTTP-запитами, а драйвер керує браузером. Перевірки стану та explicit waits багаторазово опитують браузер, тому на віддаленому запуску через BrowserStack або іншу інфраструктуру network latency відчутно сповільнює тести й змушує змінювати polling interval. Playwright підтримує постійний двосторонній зв'язок із браузером і отримує результат виконаної команди через WebSocket. У відео це подається як причина меншої кількості мережевих затримок, кращої поведінки на remote execution і можливості працювати з Chromium, Firefox та WebKit через спільний API.

Playwright для Java: основи та поглиблення →

Java · Основний курс · 17:00–21:40

Навіщо потрібен власний врапер і де він стає технічним боргом

Чистий Selenium API придатний до роботи, але тест швидко стає багатослівним. На проєктах це часто приводить до самописних фреймворків, у яких різні Page Objects використовують різні реалізації кліку, пошуку й очікувань. Без одного спільного контракту така обгортка накопичує дублювання та ускладнює супровід. Принципи Selenium однакові для Java, Python, C#, Ruby та інших bindings: клієнт надсилає команди WebDriver, драйвер взаємодіє з браузером. Тому важливіше розуміти модель драйвера, waits, локатори й test runner, ніж запам'ятовувати лише синтаксис однієї мови.

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

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

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

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

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

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

`WebDriverWait`, `FluentWait` і polling interval

Окремий клас waits створює `WebDriverWait` для поточного драйвера з timeout 10 секунд. `pollingEvery(Duration.ofMillis(100))` означає, що до завершення timeout умова перевірятиметься приблизно кожні 100 мс. `WebDriverWait` наслідує `FluentWait`, тому обидва мають спільну основу: timeout, polling і можливість ігнорувати визначені exceptions. Різниця в API не заважає передати до `until` власну lambda або `ExpectedCondition`, яка перевіряє кілька властивостей за один виклик.

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

Java · Додаткові матеріали · 56:30–1:03:35

Запуск, діагностика та коректні очікування

Перший запуск показує проблему з переходом між сторінками. Тимчасовий `sleep(10000)` допомагає підтвердити, що причина — асинхронне завантаження, але не має залишатися у фінальному тесті. Замість фіксованої затримки тест очікує конкретний елемент чи текст нової сторінки. Перевірка лише URL недостатня: адреса може змінитися раніше, ніж DOM стане готовим.

Створення першого Java-проєкту та тесту →

Java · Основний курс · 1:10:00–1:16:56

Стабілізація перевірок і підготовка коду до коміту

Перед статичним читанням тексту додається очікування видимості елемента, щоб уникнути перевірки ще не завантаженого стану. Page Object може містити очікування того, що користувач бачить на сторінці, тоді як тест зберігає бізнес-порівняння отриманого значення. Після рефакторингу сценарій читається як послідовність дій через `SignInPage`, `ProjectsPage` і `ProjectPage`, а реалізація рознесена між відповідними класами. Наприкінці показано `Reformat Code` та `Optimize Imports`: IDE прибирає зайві імпорти й упорядковує статичні та нестатичні поля й методи. Автоматичне форматування перед комітом не замінює запуск тестів, бо зміна порядку ініціалізації може зламати код. Звичка — очистити імпорти, відформатувати код і перевірити його до коміту.

Page Objects: рефакторинг тестів →

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

Case-insensitive перевірка тексту

Перевірка очікуваного тексту падає через різний регістр. Готовий `textToBePresentInElement` перевіряє входження, але не розв'язує вимогу case-insensitive comparison у потрібній формі. Для `textMatches` створюється `Pattern` із прапорцем `CASE_INSENSITIVE`; очікуваний текст передається до pattern як конкретне значення. Після цієї зміни тест проходить, а фінальний wrapper має окремі реалізації пошуку, actions і waits замість дублювання Selenium-викликів у Page Objects.

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

Java · Основний курс · 1:35:10–1:41:30

Діагностика waits і власні `ExpectedCondition`

`WebDriverWait` можна доповнити власним timeout message і переліком exceptions, які ігноруються під час polling. Як приклад розглядається `StaleElementReferenceException`: якщо DOM оновився між двома перевірками, wait може повторити умову замість негайного падіння. Ігнорувати всі exceptions без розбору не радять — перелік має відповідати очікуваним перехідним станам. Власна умова може через lambda знайти елемент і послідовно перевірити `isDisplayed()`, `isEnabled()` та текст. Її текстове представлення або окремий message потрапить до timeout diagnostics. Для складної перевірки це дає контроль над поведінкою, але готові `ExpectedConditions` варто перевикористовувати, доки вони виражають потрібний контракт.

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

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