web-first assertion
Assertion, який автоматично повторює перевірку до очікуваного стану або timeout, наприклад to_be_visible чи to_be_enabled.
Що має описувати isLoaded →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Мінімальна бізнес-готовність checkout
Перевірка фіксує лише сигнали, без яких користувач не може перейти до payment action; вона не перевіряє кожен animation frame або весь DOM.
Функція завершується лише після готовності ключових checkout controls.
Що має описувати isLoaded →Пошук проєкту через семантичні locators
Мінімальна helper-функція перевіряє видимість поля, заповнює його й очікує видимий heading з назвою проєкту.
У target application поле Search заповнюється, а потрібний heading стає видимим.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →Створити два postfix templates
Створіть Python postfix template locator, який обгортає вираз у page.locator(...).
Створіть postfix template expvis для expect(...).to_be_visible().
Перевірте обидва шаблони на трьох різних селекторах і переконайтеся, що лапки не дублюються.
Кожен шаблон стабільно створює синтаксично валідний Python-код, а курсор залишається в очікуваному місці.
Role locator і видимість діалогу
Мінімальний приклад Codex на основі актуального Playwright contract: інтерактивна кнопка знаходиться за role та accessible name, а неінтерактивний текст перевіряється через get_by_text().
Після кліку на Create suite текст Select suite for test стає видимим.
Майструємо IDE під себе →User-facing locator зі scope
Демонструє narrowing до desktop container, user-facing locators і explicit assertion; URL та labels є навчальними placeholders.
Test знаходить лише desktop form і перевіряє повідомлення про невалідний login.
3. Селектори та пошук елементів →Наявність тексту не дорівнює видимості
Експеримент показує, що `to_have_text()` може успішно знайти текст у прихованому DOM-елементі. Отже, така перевірка не доводить, що користувач бачить проєкт після фільтрації. Для цього сценарію точніша перевірка — `to_be_visible()`. Висновок узагальнюється: assertion треба обирати за реальною вимогою. Якщо контракт про видимість — перевіряємо видимість; якщо про текстове значення незалежно від відображення — тоді `to_have_text()`.
Перевірка повідомлення про помилку
Для невалідних облікових даних тест очікує повідомлення `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" ) ``` У першому випадку елемент знаходиться за текстом і перевіряється його видимість. У другому — спочатку знаходиться стабільний контейнер, а потім перевіряється його текст. Обидва варіанти потребують правильної області пошуку через дубльовану розмітку.
Семантичний локатор поля пошуку
Поле пошуку знаходиться через `get_by_role("searchbox", name="Search")`. Такий локатор спирається на доступну роль і назву елемента, тому краще відображає намір користувача, ніж випадковий CSS-клас. Перед заповненням поля перевіряється `to_be_visible()`. Назва цільового проєкту зберігається у змінній, бо це одне й те саме предметне значення для введення та подальшого очікування.
Власні postfix templates для Playwright
`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`. Результат детермінований і не потребує повторної перевірки припущень генеративної моделі.
Pick locator і генерація assertions
У Codegen можна перемкнутися з повного запису на Pick Locator і вибирати окремі елементи. Режими assertions генерують перевірки видимості, тексту або значення: ```python expect(page.get_by_text("Invalid email or password")).to_be_visible() ``` або перевірки вмісту контейнера через `to_contain_text`. Практичний цикл: записати короткий сценарій, скопіювати код у PyCharm, запустити його, а потім прибрати зайві дії та виправити локатори. Саме так автор свого часу використовував recorder для вивчення Playwright API.
Пошук кнопки Login і strict mode
Для перевірки видимості кнопки використовується `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.
Дані Faker, запуск і перевірка сценарію
Для унікальної назви використовується Faker. Вираз із назвою компанії перетворюється на змінну через створений postfix template, змінна перейменовується на змістовну `target_suite_name` і передається в метод створення. Непотрібні вбудовані postfix templates можна вимикати, щоб список підказок не заважав. Водночас експеримент із власним `.var` показує межу автоматизації: якщо шаблон не залишає курсор у корисному місці, його треба виправити, а не пристосовувати робочий процес до невдалого шаблону. Сценарій запускається й проходить послідовно: авторизація, створення проєкту, закриття README, відкриття діалогу створення тесту. У режимі паузи перевіряється DOM і вибирається текст `Select suite for test`; для нього додається шаблон `get_by_text(...)`, після чого `expect(...).to_be_visible()` підтверджує появу модального вікна. Якщо попередній debug-процес ще приєднаний, повторний запуск може чекати на його завершення. Після коректного продовження або зупинки процесу тест проходить. Наприкінці тест перейменовується відповідно до перевірюваної поведінки, а не до проміжних технічних кроків.