Locators — Playwright Python
Описує recommended locators, test ids, CSS/XPath fallback, chaining і strictness.
3. Селектори та пошук елементів → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Selenium Manager
Вбудований CLI-інструмент Selenium, який bindings використовують як fallback для автоматизованого керування browser drivers і, за потреби, браузерами.
1. Selenium початок, основи, фікстури →Selenium Manager
У відео Selenium Manager описано як автоматичний механізм, через який webdriver.Chrome() отримує потрібний driver без ручного шляху.
Станом на 2026-07-31 офіційна документація описує Selenium Manager як fallback, коли driver не передано або не знайдено. Він постачається з bindings від Selenium 4.6, підтримує керування браузерами від 4.11 і досі позначений як Beta.
Selenium 4.6 для bundled driver management; Selenium 4.11 для automated browser management
1. Selenium початок, основи, фікстури →Доказ незалежності Free fixture
Видаліть локальні state-файли.
Запустіть лише один Free test і перевірте створення state через fallback.
Запустіть той самий тест вдруге й перевірте повторне використання state без другої page.
Обидва запуски проходять окремо; перший створює state, другий його використовує, одночасно відкрита одна page.
Підтвердити reporting flow
Додайте один allure.step до публічної Page Object action.
Згенеруйте allure-results для одного green і одного failed test.
Додайте screenshot та окремий Playwright trace artifact для failure.
Згенеруйте static report і окремо відкрийте published URL.
Зафіксуйте, чи доступний trace end to end; не прибирайте fallback без цього доказу.
Порівняти три locators
Вибрати одну важливу дію в UI.
Написати user-facing locator, test id locator і короткий CSS fallback.
Змінити translation та experiment variant.
Обрати найстабільніший locator і зафіксувати його contract.
Обраний locator залишається однозначним у контрольованих variants, а причина вибору описана одним абзацом.
Експеримент із Playwright trace attachment
Навмисно створюється failure, щоб перевірити новий content type для Playwright trace в Allure. У цьому Python setup очікуваний інтерактивний trace у report не з’являється. Автор не видає припущення за успіх і залишає робочий fallback: зберігати traces окремим artifact та відкривати їх через Playwright Trace Viewer. Таким чином Allure покращує навігацію по tests і steps, але не замінює перевірену trace-діагностику, доки конкретна інтеграція не підтверджена end to end.
Fallback для чистого запуску
Fallback будує context, створює page, авторизується, переходить до Free проєкту й записує `storage_state`. Після цього та сама page передається тесту через `yield`, щоб сценарій продовжився без повторного відкриття вкладки. Під час демонстрації код кілька разів дублюється для швидкої перевірки, а потім уточнюється. Ключовий критерій — окремий Free test має проходити самостійно після видалення всіх локальних state-файлів.
Помилки parsing і зовнішні дані
Перетворення `int("not-a-number")` спричиняє `ValueError`. Подібні помилки виникають із CSV, UI text або API payload, коли фактичний формат не відповідає очікуваному. Fallback на `0` чи інше значення допустимий лише коли це частина явного контракту; інакше він приховає дефект даних.
Повне покриття варіантів
Якщо `result` створюється лише всередині гілок, неочікуване значення може залишити змінну неініціалізованою. Мінімальні безпечні варіанти — початковий `result = "unknown"` або завершальний `else`. Це важливо для нестандартних status codes та пошкоджених test data.
Словники як модель API-даних
`dict` зберігає пари key/value й природно представляє JSON-like payload або response. `user["email"]` читає обов’язкове поле та падає, якщо ключа немає; `user.get("displayName", "not provided")` дозволяє явно задати fallback для optional field.
Читабельний CSS як практичний fallback
Якщо стабільного test ID або accessible name немає, припустимий короткий CSS selector через зрозумілий parent і тип дочірнього елемента. Locator повинен читатися; складний вираз варто сховати за змінною з предметною назвою. Не слід використовувати generated hashes, випадкові class names, positional indexes або повні DOM paths. Якщо ID має стабільний префікс і випадковий suffix, можна шукати за контрольованим частковим збігом.
Ціна товару як розподілений бізнес-процес
[Дивитися з 17:28](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1048s). Один `Get Products` може агрегувати базову інформацію, зображення з object storage, персональну або гуртову ціну, VAT, промо-правила, related products і дані зовнішнього податкового провайдера. Розрахунок залежить від типу покупця, країни, собівартості та локального законодавства. Державні реєстри чи їхні агрегатори можуть бути платними, повільними або недоступними, тому відповіді кешуються. Через це тест має визначити джерело кожного поля, правила fallback, паралельні залежності, cache hit/miss та допустиму застарілість даних, а не лише порівняти один JSON із очікуваним.
Окрема fixture і виявлення прихованої залежності
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.