Explicit wait
Polling loop, який очікує конкретну умову до timeout і завершується результатом condition або TimeoutException.
1. Selenium початок, основи, фікстури →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Locator-based expected condition
Expected condition, яка приймає locator tuple й виконує пошук під час polling, на відміну від condition для вже знайденого WebElement.
2. Selenium організація PageObject's та Очікувань →Явне очікування видимого елемента
Locator передається всередину expected condition, тому кожна спроба polling може повторно знайти актуальний DOM-вузол.
Повертається видимий WebElement або після 10 секунд виникає TimeoutException.
1. Selenium початок, основи, фікстури →Вартість polling і `StaleElementReferenceException`
WebDriver перевіряє стани елементів через браузер і JavaScript. Надто частий polling може впливати на сторінку, яку тест вимірює, особливо якщо UI одночасно виконує важку клієнтську логіку. Тому частоту й timeout варто тримати розумними, а кількість UI-тестів — достатньою для критичних journeys, не максимальною. Іноді короткий `sleep` може бути прагматичним, якщо саме polling блокує потрібний browser work, але це виняток із виміряною причиною. За замовчуванням очікується конкретний спостережуваний стан через explicit wait. `StaleElementReferenceException` виникає, коли WebDriver зберіг internal ID елемента, а компонент перерендерився й старий DOM-вузол зник. Повторний виклик дії на старому `WebElement` уже не може спрацювати; потрібен повторний пошук за locator.
`WebDriverWait` та `expected_conditions`
Явне очікування створюється як `WebDriverWait(driver, timeout, poll_frequency=...)`. Timeout задає верхню межу, а `poll_frequency` — інтервал повторної перевірки. Значення треба підбирати без надмірного polling: частіші запити не лікують повільний продукт і можуть додати зайве навантаження браузеру. Метод `until()` приймає конкретну умову з `selenium.webdriver.support.expected_conditions`, яку часто імпортують як `EC`. Серед типових умов: `visibility_of_element_located`, `element_to_be_clickable`, presence, invisibility і selected state. До `WebDriverWait` можна передати ignored exceptions, наприклад `NoSuchElementException` або `StaleElementReferenceException`. Проте це працює лише тоді, коли пошук виконується всередині condition; якщо `find_element()` викликати раніше під час формування аргументу, exception виникне ще до старту polling.
Local і remote execution
Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.
Від сирого сценарію до Page Object
Стартовий тест напряму викликає `driver.find_element()`, `WebDriverWait(...).until(...)` і браузерні дії. Він придатний для перевірки ідеї, але змішує бізнес-сценарій із технікою Selenium, тому наступний крок — дати діям читабельні назви й рознести їх по Page Objects. Замість Playwright `Page` у конструктор Page Object передається Selenium WebDriver. Спільний `BasePage` зберігає driver і один раз ініціалізує стандартне очікування, щоб кожен клас сторінки не дублював timeout та polling configuration. Найпрактичніше представлення локатора — tuple на кшталт `(By.CSS_SELECTOR, "...")`. Воно зберігає і стратегію, і значення пошуку та напряму сумісне з locator-based expected conditions.
`while` і обмежені retries
`while` повторює блок, поки умова truthy. У retry-прикладі є `attempt`, `max_attempts`, пауза та обов’язкове `attempt += 1`; без оновлення counter цикл зависне. Для реальних UI-тестів framework-native waits кращі за ручний polling, але bounded `while` може бути корисним для контрольованої перевірки backend state.
Не змішувати implicit та explicit waits
Locator-based explicit wait вирішує stale reference тим, що на кожній спробі знаходить актуальний DOM-вузол. Це ще одна причина зберігати локатор, а не довгоживучий `WebElement`. Implicit wait радять залишити нульовим і не змішувати з explicit waits: інакше внутрішнє очікування кожного `find_element()` додається до зовнішнього polling, через що реальний timeout стає непередбачуваним. Практичне завдання — зробити `BasePage`, окремий wait helper і Page Object у вибраному locator-based стилі.