Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Приклад завантажує сусідній .env, перевіряє всі обов’язкові keys і завершується з явною помилкою, якщо конфігурація неповна.
Для підготовленого .env друкується https://example.test; при відсутньому key виникає RuntimeError.
Python convention: name з одним leading underscore вважається implementation detail. Подвійний leading underscore запускає name mangling для уникнення конфліктів, але не гарантує privacy.
__init__, self, page та принципи ООП →Playwright Test надає isolated page, а locators виражають user-facing contract через label, role і accessible name.
Test проходить лише проти application, що має наведений login contract.
Що має вміти та знати мідл автоматизатор →Знайдіть у власному тесті інтерактивний елемент, який зараз шукається за CSS-класом або вкладеною структурою.
Перевірте його role та accessible name у Accessibility Tree.
Замініть локатор на get_by_role(..., name=...) і запустіть цільовий тест.
Локатор однозначно знаходить потрібний елемент, а тест проходить без nth(), first або прив’язки до CSS оформлення.
Мінімальний приклад Codex на основі актуального Playwright contract: інтерактивна кнопка знаходиться за role та accessible name, а неінтерактивний текст перевіряється через get_by_text().
Після кліку на Create suite текст Select suite for test стає видимим.
Майструємо IDE під себе →Class name позначає page, methods описують actions, locators зберігаються в одному місці, а open завершується мінімальною readiness check.
Після open() test продовжується лише коли heading Sign in видимий; fill_email() приховує locator details від test code.
У 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, або обрати зрозумілий контрольований локатор.
Елемент за class шукається через `.class-name` або attribute selector на кшталт `[class*='class-name']`. Два classes одного елемента записуються без пробілу: `.first.second`. Tag та `id` або attribute також можна комбінувати, наприклад `turbo-frame#global_search_results`. Якщо attribute value містить пробіл або спеціальні символи, його треба брати в лапки. У Java-рядку single quotes всередині CSS зменшують кількість escaping.
Саме оголошення `def print_hello():` нічого не виконує. Функцію треба окремо викликати. Це розділяє опис поведінки та момент її запуску. Далі функція параметризується ім’ям. Замість фіксованого `Hello World` вона приймає `name` і формує `f"Hello {name}"`, тому один алгоритм працює з різними вхідними даними.
Картку проєкту шукають як заголовок через `get_by_role("heading", name=target_project)`. Відео порівнює це з CSS-пошуком на кшталт `ul h3`: семантичний варіант зазвичай чіткіше пояснює, що саме очікує тест. Окремо показано, що блоки Python визначає відступ. Положення курсора й відступи впливають на те, чи IDE запускає одну тестову функцію, чи весь файл. Після двокрапки тіло функції має бути послідовно відформатоване.
Один underscore, наприклад `_locator`, — домовленість «внутрішня деталь, не використовуй без потреби». Інтерпретатор не забороняє доступ. Подвійний початковий underscore запускає name mangling, щоб зменшити випадкові конфлікти в нащадках, але теж не створює security boundary. На відміну від `private` або `protected` у статично типізованих мовах, Python більше покладається на дисципліну автора й користувача класу. IDE може попередити про звернення до non-public member, але виконання зазвичай можливе.
Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Class name зазвичай є іменником в однині та пишеться з великої літери. `__init__` приймає початковий state, а `self.email` і `self.role` належать конкретному object instance. Method `is_admin()` розміщує перевірку ролі біля даних і не змушує кожен test повторювати `user.role == "admin"`.
`#search` знаходить елемент з `id="search"`. Довільний attribute записується у квадратних дужках: `[name='viewport']`. Коли значення має стабільну частину та змінний hash, оператор `*=` дає пошук за підрядком. Це корисно для generated attributes у frontend frameworks, але стабільна частина має бути досить специфічною, щоб не отримати кілька збігів.
Chrome DevTools дозволяє подивитися accessibility tree й accessible name, навіть якщо значення неочевидне з HTML. Текстові locators зручні, доки labels, placeholders і переклади стабільні. Для багатомовного продукту або content, який окремо змінює контент-команда, стабільний `data-testid` часто кращий. Атрибути можуть рендеритися по-різному залежно від frontend framework, а generated classes та IDs змінюватися між builds, тому вибір залежить від реального контракту команди.