Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Перевірка фіксує лише сигнали, без яких користувач не може перейти до payment action; вона не перевіряє кожен animation frame або весь DOM.
Функція завершується лише після готовності ключових checkout controls.
Що має описувати isLoaded →Мінімальна helper-функція перевіряє видимість поля, заповнює його й очікує видимий heading з назвою проєкту.
У target application поле Search заповнюється, а потрібний heading стає видимим.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →Мінімальний приклад Codex на основі актуального Playwright contract: інтерактивна кнопка знаходиться за role та accessible name, а неінтерактивний текст перевіряється через get_by_text().
Після кліку на Create suite текст Select suite for test стає видимим.
Майструємо IDE під себе →Демонструє narrowing до desktop container, user-facing locators і explicit assertion; URL та labels є навчальними placeholders.
Test знаходить лише desktop form і перевіряє повідомлення про невалідний login.
3. Селектори та пошук елементів →Playwright Test надає isolated page, а locators виражають user-facing contract через label, role і accessible name.
Test проходить лише проти application, що має наведений login contract.
Що має вміти та знати мідл автоматизатор →Playwright expect(...) повторно перевіряє умову до успіху або завершення timeout, що прибирає потребу в ручних sleep для очікування UI-стану.
`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`. Результат детермінований і не потребує повторної перевірки припущень генеративної моделі.
Тест відкриває сайт через `page.goto(...)`, після чого `expect(page).to_have_title(...)` перевіряє заголовок вкладки. `expect` виконує очікування протягом заданого тайм-ауту, тому така перевірка стійкіша за миттєве порівняння значень. ```python def test_open_home_page(page: Page): page.goto("https://testomat.io") expect(page).to_have_title("очікуваний заголовок") ``` Автодоповнення PyCharm шукає методи не лише за початком, а й за частиною назви. Методи з подвійними підкресленнями є службовими й у звичайному тесті не потрібні.
У курсі використовується синхронний API Playwright, щоб кроки тесту виконувалися послідовно без додаткової складності `async`/`await`. Фікстуру можна типізувати класом `Page`, а PyCharm імпортує потрібне ім’я через quick fix: ```python from playwright.sync_api import Page, expect def test_open_home_page(page: Page): ... ``` Важливо імпортувати `Page` і `expect` саме з `playwright.sync_api`, а не з асинхронного API.
У Codegen можна перемкнутися з повного запису на Pick Locator і вибирати окремі елементи. Режими assertions генерують перевірки видимості, тексту або значення: ```python expect(page.get_by_text("Invalid email or password")).to_be_visible() ``` або перевірки вмісту контейнера через `to_contain_text`. Практичний цикл: записати короткий сценарій, скопіювати код у PyCharm, запустити його, а потім прибрати зайві дії та виправити локатори. Саме так автор свого часу використовував recorder для вивчення Playwright API.
[Дивитися з 40:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2400s). Кілька переходів у implementation показують ланцюг від `Locator.click()` до frame/channel command. Client збирає action options і надсилає повідомлення через connection; browser-side layer виконує пошук, actionability checks і дію. Під час дослідження автор спочатку припускає, що assertions повністю виконуються в Python client, а потім знаходить protocol command для locator expect. Практичний урок тут важливіший за конкретний internal class: перевіряти припущення переходом у реалізацію, trace або protocol logs і явно коригувати висновок, коли source code показує інше.
Для невалідних облікових даних тест очікує повідомлення `Invalid email or password`. Є два близькі підходи: ```python expect(page.get_by_text("Invalid email or password")).to_be_visible() expect(page.locator("#content-desktop .common-flash-info")).to_have_text( "Invalid email or password" ) ``` У першому випадку елемент знаходиться за текстом і перевіряється його видимість. У другому — спочатку знаходиться стабільний контейнер, а потім перевіряється його текст. Обидва варіанти потребують правильної області пошуку через дубльовану розмітку.
HTML потрібного елемента можна передати AI-помічнику з проханням запропонувати Playwright-локатор. Це корисно на початку, коли синтаксис CSS, XPath і role-локаторів ще незнайомий. Згенерований код не можна приймати без запуску. AI може запропонувати статичну перевірку або локатор, що знаходить не той вузол. Для UI-тесту зазвичай кращий `expect`, який очікує потрібного стану й дає змістовну помилку. Кожну пропозицію треба перевіряти в DevTools та реальним тестовим прогоном.
Плагін, що аналізує всю сторінку, швидко створює десятки локаторів і методів. У демонстрації результат надмірний: зайві imports, асинхронний API, складні обгортки та невдалі перевірки на кшталт `is_element_visible`. Статична перевірка видимості дає гіршу діагностику й не використовує автоматичне очікування Playwright. Для тесту краще залишати дії простими, а очікуваний стан виражати через `expect`. Велика кількість автоматично згенерованого коду збільшує обсяг підтримки, не гарантуючи стабільності.
Для перевірки видимості кнопки використовується `expect(locator).to_be_visible()`. У відео порівнюються перші варіанти локаторів: - CSS-клас: `.login-item`; - текстовий локатор: `page.get_by_text("Login")`; - точний текст: `page.get_by_text("Login", exact=True)`. Якщо локатор знаходить кілька вузлів, Playwright у strict mode не виконує дію навмання. Потрібно зробити критерій однозначним, а не бездумно брати перший елемент. `exact=True` обмежує пошук повним текстовим збігом; його документацію можна відкрити через швидку довідку PyCharm.
Для частих операцій створюються малі шаблони, кожен з яких прибирає конкретний повторюваний фрагмент: - `page.pause()` для зупинки тесту й дослідження стану; - заготовка методу Page Object із параметром і локатором; - `self.page.get_by_role(...)` з курсором на ролі та подальших аргументах; - виклик потрібного локатора з `.click()`; - очікування `expect(button).to_be_hidden()` після відправлення форми. Шаблон `get_by_role` дає виграш не кількістю згенерованого коду, а тим, що не треба щоразу набирати `self.page`, назву методу й дужки. Після розгортання залишається вибрати роль, наприклад `button`, і вказати доступне ім’я. Також показано запуск поточного тесту зі скорочення та переміщення цілого statement вгору або вниз (`⌘⇧↑` / `⌘⇧↓` у демонстрації). Якщо комбінації в локальному keymap інші, дію слід знайти за назвами `Move Statement Up` і `Move Statement Down`. Після кліку тест очікує зникнення кнопки. Це робить перехід до наступної сторінки явним: подальші дії починаються лише після підтвердженої зміни стану.