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

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

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

`WebElement` проти `By` усередині очікування

Перший запуск падає з `NoSuchElementException`, хоча елемент згодом з'являється на сторінці. Причина — `findElement` виконується ще до входу в `wait.until(...)`: Selenium спочатку намагається передати готовий `WebElement`, і очікування не отримує можливості повторювати пошук. Коли в `ExpectedConditions` передається `By`, локатор залишається всередині циклу очікування. Тоді `WebDriverWait` протягом заданого timeout повторно перевіряє, чи знайдений елемент і чи містить він потрібний текст. Для динамічної сторінки варіанти на кшталт `visibilityOfElementLocated(By)` і `textToBePresentInElementLocated(By, text)` гнучкіші за умови, які приймають уже знайдений `WebElement`.

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 · Основний курс · 1:41:30–1:44:07

Реалізація `ExpectedConditions` і межа між перевіркою та дією

Наприкінці відкривається код готових conditions. `elementToBeClickable` спочатку перевіряє visibility, а потім enabled state. Між цими операціями DOM може оновитися, тому навіть складена умова має коротке вікно для `StaleElementReferenceException`; polling та обробка перехідної помилки визначають, чи буде зроблена наступна спроба. Створений Selenium-врапер слугує підготовкою до наступної теми — аналогічної обгортки над Playwright. Принципи залишаться подібними, але API та спосіб взаємодії з браузером матимуть інший синтаксис.

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

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:35:10–1:41:30

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

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

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

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