Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Вибрати одну важливу дію в UI.
Написати user-facing locator, test id locator і короткий CSS fallback.
Змінити translation та experiment variant.
Обрати найстабільніший locator і зафіксувати його contract.
Обраний locator залишається однозначним у контрольованих variants, а причина вибору описана одним абзацом.
Page Objects передають locator tuple у BasePage, а кожна дія очікує власну перевірювану передумову.
click() працює лише з видимим і enabled елементом; type_text() — з видимим елементом.
2. Selenium організація PageObject's та Очікувань →Режим Inspector для вибору element, preview locator, ручного refinement і копіювання locator у code.
4. Playwright плагіни та codegen →Знайти всі збіги тексту Login у DevTools.
Побудувати locator з role/name або стабільним attribute.
Перевірити, що locator знаходить рівно один видимий element.
Дія не потребує .first або випадкового індексу.
Вибрати три interactive elements на тестовій сторінці.
Для кожного записати role/text/test-id/CSS candidates.
У DevTools перевірити count і видимість.
Обрати один locator та пояснити компроміс.
Кожен selected locator однозначний і пояснюваний на code review.
Поточний Playwright Codegen намагається вибрати resilient locator, пріоритезуючи role, text і test id, та уточнює locator, якщо match не унікальний. Generated result усе одно потребує review.
4. Playwright плагіни та codegen →На Python-проєктах можна зустріти три підходи: зберігати locator tuple, лише CSS/XPath-рядок або вже знайдений `WebElement`. Рядок коротший, але не містить тип пошуку; `WebElement` зручний лише поки DOM-вузол не перерендерився; locator дає змогу безпечно виконувати повторний пошук. Якщо helper має приймати і locator, і `WebElement`, це можна відобразити union type та всередині визначити потрібну expected condition. Така гнучкість виправдана лише коли обидва представлення реально використовуються; для нового коду один locator-based контракт простіший. Wait helper отримує default timeout, але дозволяє локально передати довший для справді повільної операції. Page Object може застосовувати Loadable Component approach: сторінка вважається готовою лише після появи її ключових елементів, наприклад email і password inputs.
[Дивитися з 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.
`Postfix Completion` налаштовується через Settings (`⌘,` на macOS). Postfix template застосовується до виразу ліворуч від крапки. Спеціальна змінна `$EXPR$` означає цей вираз, а `$END$` визначає, де залишиться курсор після розгортання. Створено кілька Python-шаблонів: - `"selector".locator` перетворює селектор на `page.locator("selector")`; - вираз із postfix `expect` обгортається в `expect(...)`; - скорочений варіант на кшталт `expvis` одразу створює `expect(...).to_be_visible()`. Під час першого налаштування `locator` вираз помилково був додатково взятий у лапки, через що PyCharm формував неправильний код. Після виправлення `$EXPR$` підставляється як готовий вираз. Це важливе правило: шаблон має додавати лише відсутню структуру, а не повторно форматувати вже валідний фрагмент. Такий ланцюжок скорочує типовий шлях до перевірки: знайти селектор, вставити його як рядок, застосувати `.locator`, а потім `.expvis`. Результат детермінований і не потребує повторної перевірки припущень генеративної моделі.
Locator Assistant дає змогу вибрати елемент на сторінці й отримати варіант Python-локатора, наприклад `get_by_role(...)` або `get_by_text(..., exact=True)`. Інструмент може допомогти згадати синтаксис, але взаємодія не завжди зручна: вибір елемента потрібно щоразу запускати заново, підсвічування може бути неочевидним, а вбудована перевірка іноді не знаходить елемент, для якого сам плагін щойно згенерував локатор. Результат слід вставити в DevTools або тест і перевірити незалежно.
У Codegen можна перемкнутися з повного запису на Pick Locator і вибирати окремі елементи. Режими assertions генерують перевірки видимості, тексту або значення: ```python expect(page.get_by_text("Invalid email or password")).to_be_visible() ``` або перевірки вмісту контейнера через `to_contain_text`. Практичний цикл: записати короткий сценарій, скопіювати код у PyCharm, запустити його, а потім прибрати зайві дії та виправити локатори. Саме так автор свого часу використовував recorder для вивчення Playwright API.
Playwright підтримує тривалий двосторонній канал із browser process і через browser-specific protocol передає команди click, fill, navigation та читання стану. Locator actions мають auto-waiting: перед дією Playwright перевіряє релевантні actionability conditions — наприклад, видимість, стабільність, можливість отримати events і editable state. Це дозволяє тесту формулювати намір «виконай click для цього locator», а orchestration layer бере на себе очікування готовності елемента в межах timeout. Auto-waiting не усуває потребу в assertion: після дії все одно треба перевірити очікуваний результат. Основні browser engines Playwright — Chromium, Firefox і WebKit. WebKit наближає поведінку Safari, але не є повною копією всіх Safari/macOS/iOS інтеграцій. Branded Chrome або Edge можуть запускатися як Chromium channels, проте повну browser matrix потрібно визначати з реальної product analytics і support policy.
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Trace показує реальну причину: на CI hover відбувся, але очікуваний UI state не став видимим так, як локально. Це звужує проблему з абстрактного «тест падає на CI» до конкретної взаємодії браузера й locator assertion. У демонстрації перевірка адаптується для CI/headless режиму, а також розглядається примусова взаємодія. Такий workaround треба застосовувати лише після перегляду trace: інакше легко приховати реальний дефект сторінки або тесту.
Варто розуміти порядок, у якому test runner завантажує модулі, створює suite/test fixtures, запускає setup, test і teardown. Declaration задає ім'я та тип, assignment присвоює значення, а runtime initialization створює фактичний стан під час виконання програми. Точні терміни залежать від мови, але практичне питання однакове: коли ресурс уже існує й хто ним володіє. На співбесіді можуть попросити пояснити різницю між class та object, відрефакторити тест або написати надійний locator. Потрібно знати CSS/XPath настільки, щоб читати старий код, і віддавати перевагу user-facing locator API Playwright, коли семантична роль або label точніше виражає контракт.
[Дивитися з 20:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1200s). Timeout можна задавати для конкретної operation або централізовано на рівні page/context. Локальні довільні timeout-и у кожному locator виклику ускладнюють поведінку suite, тому корисніше мати послідовну default policy й змінювати її лише для підтверджених винятків. У відео розбираються load states `domcontentloaded`, `load` і `networkidle`, а також події detach, close та navigation timeout. `networkidle` не є універсальним доказом готовності application: сучасна сторінка може мати постійний network traffic. Надійніша перевірка — очікування конкретного observable UI state через locator або web-first assertion. Стабільний element означає, що його bounding box не змінюється протягом послідовних animation frames. Це захищає від кліку в element, який ще рухається або змінює розмір під час layout/animation.