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

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

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 · Сесії: AMA та PMP · 14:20–20:00

Actionability і правильна область кліку

[Дивитися з 14:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=860s). Перед дією Playwright перевіряє її передумови. Для `locator.click()` це, зокрема, strict resolution до одного елемента, visibility, stability, здатність отримувати pointer events і enabled state. Якщо умови не виконуються до завершення timeout, action завершується помилкою замість випадкового кліку. Візуальний текст усередині button не завжди є правильним click target: event listener може бути на батьківському element, а вкладений `span` — лише оформленням. Через це семантичний locator на кшталт `getByRole('button', { name: ... })` часто стабільніший за пошук найглибшого text node. Велика активна область також краща для користувача й доступності. Вибір між `click()` і touch-oriented `tap()` має залежати від реального input mode та context configuration, а не лише від розміру viewport.

Як Playwright взаємодіє з браузером через протокол →

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

Лінивий пошук як основа стабільного врапера

Тест знову падає до виконання text wait, бо `ElementActions` отримує готовий `WebElement`: eager пошук завершується помилкою раніше, ніж запускається очікування. Додавання visibility wait безпосередньо до `find` теж створює суперечність для сценарію, який навмисно очікує invisibility. Рішення — зберігати в `ElementActions` не `WebElement`, а `By`. Реальний пошук виконується лише тоді, коли потрібна дія або конкретна умова. Так один і той самий locator можна використати для visibility, invisibility чи text check, не нав'язуючи стан на етапі створення wrapper object.

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

Java · Сесії: AMA та PMP · 0:00–4:40

Від публічного API до реалізації Locator

[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.

Як Playwright взаємодіє з браузером через протокол →

Java · Додаткові матеріали · 2:10–4:15

Публікація локального проєкту

Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.

Публікація Java-проєкту на GitHub →

Java · Сесії: AMA та PMP · 4:12–5:35

Перевіряємо готовність, а не ідеальність анімації

Не потрібно перевіряти кожен кадр анімації. Достатньо спостережуваного переходу: loader зник, skeleton замінився карткою, назва продукту видима, критична дія доступна. Уповільнення мережі в DevTools допомагає знайти реальні проміжні стани й вибрати правильний сигнал. Підсумкове правило: `isLoaded` описує те, що користувач очікує побачити перед продовженням роботи, і те, без чого тест не може виконувати наступну дію стабільно.

Що має описувати isLoaded →

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

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

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

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

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