Locators
Фіксує актуальну рекомендацію пріоритезувати user-facing locators, зокрема get_by_role(), get_by_label() і get_by_text().
Майструємо IDE під себе → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Role locator
Playwright locator, який знаходить елемент за доступною роллю та зазвичай accessible name. Офіційна документація радить пріоритезувати user-facing attributes і explicit contracts на кшталт get_by_role().
Майструємо IDE під себе →Замінити крихкий локатор на user-facing locator
Знайдіть у власному тесті інтерактивний елемент, який зараз шукається за CSS-класом або вкладеною структурою.
Перевірте його role та accessible name у Accessibility Tree.
Замініть локатор на get_by_role(..., name=...) і запустіть цільовий тест.
Локатор однозначно знаходить потрібний елемент, а тест проходить без nth(), first або прив’язки до CSS оформлення.
Семантичний локатор поля пошуку
Поле пошуку знаходиться через `get_by_role("searchbox", name="Search")`. Такий локатор спирається на доступну роль і назву елемента, тому краще відображає намір користувача, ніж випадковий CSS-клас. Перед заповненням поля перевіряється `to_be_visible()`. Назва цільового проєкту зберігається у змінній, бо це одне й те саме предметне значення для введення та подальшого очікування.
Accessibility tree та role-локатори
Accessibility tree показує інтерфейс так, як його сприймають assistive technologies: ролі `link`, `button`, `textbox`, `searchbox`, `list` та їхні доступні імена. У DevTools потрібно ввімкнути повне accessibility tree й перезавантажити сторінку. Playwright підтримує локатори на основі цієї семантики, наприклад `get_by_role`. Вони часто добре читаються та водночас перевіряють, що елемент має зрозумілу роль. Але на проєкті все одно потрібна єдина домовленість про основну стратегію та допустимі винятки.
`get_by_role` і проблемна семантика форми
У Python role-локатор може виглядати так: ```python page.get_by_role("button", name="Sign in") page.get_by_role("textbox", name="Email") ``` Допустимі ролі й додаткові параметри можна подивитися через перехід до визначення методу в PyCharm. На розглянутій login-формі доступні імена полів сформовані невдало, а `type="text"` використано там, де доречніший `type="email"`. Через це семантичний локатор стає незручним. Це приклад того, що рекомендацію Playwright не можна застосовувати механічно: спочатку слід перевірити реальну accessibility-структуру, а якщо вона неякісна — або виправити frontend, або обрати зрозумілий контрольований локатор.
Набір коротких Playwright-шаблонів
Для частих операцій створюються малі шаблони, кожен з яких прибирає конкретний повторюваний фрагмент: - `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`. Після кліку тест очікує зникнення кнопки. Це робить перехід до наступної сторінки явним: подальші дії починаються лише після підтвердженої зміни стану.
Playwright Locator Assistant
Locator Assistant дає змогу вибрати елемент на сторінці й отримати варіант Python-локатора, наприклад `get_by_role(...)` або `get_by_text(..., exact=True)`. Інструмент може допомогти згадати синтаксис, але взаємодія не завжди зручна: вибір елемента потрібно щоразу запускати заново, підсвічування може бути неочевидним, а вбудована перевірка іноді не знаходить елемент, для якого сам плагін щойно згенерував локатор. Результат слід вставити в DevTools або тест і перевірити незалежно.
Пошук проєкту й структура Python-тесту
Картку проєкту шукають як заголовок через `get_by_role("heading", name=target_project)`. Відео порівнює це з CSS-пошуком на кшталт `ul h3`: семантичний варіант зазвичай чіткіше пояснює, що саме очікує тест. Окремо показано, що блоки Python визначає відступ. Положення курсора й відступи впливають на те, чи IDE запускає одну тестову функцію, чи весь файл. Після двокрапки тіло функції має бути послідовно відформатоване.
Завершення тесту й різниця між шаблонами
Після успішного запуску тест перейменовується відповідно до перевірюваної поведінки. Для ще одного повторюваного фрагмента створюється простий live template, який розгортається в `return self`. Це підтримує ланцюжкові виклики Page Object без повторного ручного набору. Плагіни не є основою цього процесу. У викладача встановлений Junie, але частіше для окремих задач використовується Claude Code. Головний приріст швидкості в уроці дають штатні засоби PyCharm: пошук у Settings, keymap, рефакторинги та шаблони. Параметри сторонніх плагінів варто змінювати лише під реальну потребу. Підсумкова модель трьох механізмів: - **postfix template** застосовується після виразу через крапку та обгортає або перетворює цей вираз; - **live template** розгортає за абревіатурою блок коду в позиції курсора; - **file template** створює новий файл із готовою структурою. На практиці postfix зручний для `locator` або `expect`, live template — для `page.pause()`, `get_by_role()` і повторюваних методів, а file template — для Page Object. Ці механізми доповнюють один одного й не потребують зовнішнього генератора.