Playwright Pytest Plugin Reference
Актуальний contract CLI options і fixtures pytest-playwright.
1. Налаштування Playwright та Pytest, простий репортінг → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Playwright офіційно документує `uv` поруч із `pip`
Поточний installation guide показує uv add pytest-playwright як підтриманий варіант поряд із pip і Poetry; це додатковий workflow, а не вимога переписувати урок.
pytest fixture `page`
Fixture із pytest-playwright, яка надає ізольовану Playwright Page для тесту та прибирає ручне створення browser context у базовому сценарії.
retain-on-failure
Поточна pytest-playwright CLI option для запису trace кожного тесту й видалення запису після успішного завершення.
4. Повертаємо traces, pytest hooks, рефакторинг дублювань у fixtures →Плагін уже має `retain-on-failure`
Через custom fixture architecture у відео вручну інтегровано tracing і pytest hook.
Поточний pytest-playwright plugin підтримує --tracing retain-on-failure. Якщо тест використовує стандартні plugin fixtures, спершу варто перевірити цю option; custom hook потрібен, коли lifecycle контролюється власними fixtures.
Що змінилося після запису
У Python experiment інтерактивний Playwright trace attachment у generated report не запрацював; окремий trace artifact залишився fallback.
Allure renderer документує media type application/vnd.allure.playwright-trace і різну поведінку viewer в Allure 2/3. Automatic trace detection офіційно описане для JS/TS allure-playwright, не для ланцюжка pytest-playwright → allure-pytest.
Документацію перевірено 2026-07-31; дата появи media type не встановлена.
4. Allure репорт, основи та інтеграція в CI →Чому вбудованої pytest-playwright fixture недостатньо
Проєкт сам контролює `storage_state`, авторизовані та Free contexts, відкриття й закриття page. Через це готові fixtures плагіна не покривають потрібний lifecycle, а tracing доводиться інтегрувати у власний шар. Перед tracing виправляється побічна проблема: Free test відкривав два browser instances, бо вимагав fixture, результат якої не використовував. Видалення зайвої залежності прибирає другий запуск браузера.
Від plugin fixtures до власного життєвого циклу
Стандартні pytest-playwright fixtures добре ізолюють тести: нові context/page створюються автоматично, а cleanup виконує plugin. Для великої таблиці негативних логінів це створює помітні накладні витрати, тому у відео будується власний lifecycle: один Playwright/browser instance на ширший scope і спеціальні fixtures для clean app, logged-in app та shared page. Ключова ієрархія залежностей: Playwright instance запускає browser; browser створює context; context створює page. Scope залежної fixture не може бути ширшим за ресурс, від якого вона залежить. `yield` повинен закрити рівно ті ресурси, які fixture створила. Це optimization з ціною: повторне використання page/context послаблює ізоляцію. Починати безпечніше зі стандартних function-scoped fixtures, а reuse додавати лише після виміряного bottleneck і разом із перевіреним cleanup.
Діагностика конфлікту fixture lifecycle
Після рефакторингу suite падає через змішування plugin-managed fixtures та вручну створеного sync Playwright instance. Додатково частина launch/context options дублюється в dictionary і кількох fixtures, що робить конфігурацію непослідовною. Рішення у відео — перейти на один спосіб володіння lifecycle: custom fixtures запускають Playwright і browser, а конфігурація збирається в одному місці. Частину pytest-playwright параметрів прибирають, бо custom launcher їх уже не читає. Загальний висновок: не можна одночасно очікувати, що plugin і власний код керуватимуть тим самим browser lifecycle.
Навіщо тестам явна конфігурація
Однакова конфігурація потрібна, щоб локальний запуск і CI поводилися передбачувано. У проєкті фіксуються мінімальні версії `pytest`, `pytest-playwright`, `pytest-html`, Faker та інших залежностей. Це дає IDE, pytest і CI явні передумови замість неявної залежності від локального середовища автора. На початку також показано Local History і Smart Checkout у PyCharm/IntelliJ. Ці інструменти можуть допомогти повернути локальні зміни або розібрати конфлікт під час перемикання гілки, але не замінюють Git-історію та перевірку diff.
Віртуальне середовище й залежності
PyCharm зазвичай створює для нового Python-проєкту окреме віртуальне середовище `.venv`. Воно ізолює версію Python і бібліотеки конкретного проєкту від інших проєктів на комп’ютері. У вбудованому терміналі активне середовище позначається префіксом на кшталт `(.venv)`. Термінал можна відкрити через меню дій або гарячою клавішею (`Option+F12` на macOS чи `Alt+F12` у відповідній розкладці на Windows). Для інтеграції Playwright із pytest встановлюється пакет: ```bash pip install pytest-playwright ``` Плагін надає готові pytest-фікстури, зокрема `page`, і бере на себе створення браузера, контексту та сторінки для тесту.