Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Через custom fixture architecture у відео вручну інтегровано tracing і pytest hook.
Поточний pytest-playwright plugin підтримує --tracing retain-on-failure. Якщо тест використовує стандартні plugin fixtures, спершу варто перевірити цю option; custom hook потрібен, коли lifecycle контролюється власними fixtures.
Офіційний contract scopes, dependencies і teardown fixtures.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗Plugin fixtures browser_type_launch_args і browser_context_args дозволяють перевизначити launch та context options. CLI options plugin не застосовуються до context/page, створених вручну через API.
1. Налаштування Playwright та Pytest, простий репортінг →Актуальний contract CLI options і fixtures pytest-playwright.
1. Налаштування Playwright та Pytest, простий репортінг → Першоджерело ↗Підтверджує session-scoped browser і function-scoped context/page fixtures.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗У відео рекомендовано API preconditions, reused authenticated state та незалежні test data.
Поточна документація Playwright рекомендує не комітити auth state і використовувати окремий account на parallel worker, якщо tests змінюють shared server-side state. Конкретні fixtures, directories та worker APIs слід звіряти з версією Playwright у проєкті.
Практика курсу на YOY, домашні завдання та формат ПМП →Стандартні 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.
`pytest` fixtures виконують login, отримують JWT і передають його до `ProjectController` чи `SuiteController`. Якщо token вже збережено у scope fixture, нова авторизація не потрібна. Для створення suite спершу потрібен target project. Його можна підготувати окремою fixture або отримати в самому тесті через `ProjectController.get_all()`. Вибір залежить від того, чи це спільний precondition, чи важливий крок конкретного сценарію.
Після рефакторингу suite падає через змішування plugin-managed fixtures та вручну створеного sync Playwright instance. Додатково частина launch/context options дублюється в dictionary і кількох fixtures, що робить конфігурацію непослідовною. Рішення у відео — перейти на один спосіб володіння lifecycle: custom fixtures запускають Playwright і browser, а конфігурація збирається в одному місці. Частину pytest-playwright параметрів прибирають, бо custom launcher їх уже не читає. Загальний висновок: не можна одночасно очікувати, що plugin і власний код керуватимуть тим самим browser lifecycle.
Проєкт сам контролює `storage_state`, авторизовані та Free contexts, відкриття й закриття page. Через це готові fixtures плагіна не покривають потрібний lifecycle, а tracing доводиться інтегрувати у власний шар. Перед tracing виправляється побічна проблема: Free test відкривав два browser instances, бо вимагав fixture, результат якої не використовував. Видалення зайвої залежності прибирає другий запуск браузера.
Один `conftest.py` накопичив конфігурацію, запуск браузера, створення сторінки й app-specific fixtures. Код розділяється на модулі `config`, `playwright` та `app`, а кореневий `conftest.py` лише підключає їх через `pytest_plugins`. Технічний шар створює браузер і context; app-шар виконує login, перевіряє, що цільова сторінка завантажена, і зберігає state. Такий поділ залишає місце для Firefox або інших browser options без змішування з бізнесовими переходами.
Playwright має APIs для TypeScript/JavaScript, Python, Java і .NET. Найповніша інтеграція навколо власного runner, fixtures і reporting доступна у Playwright Test для TypeScript/JavaScript; у Python за orchestration зазвичай відповідає pytest та його plugins. Selenium також має офіційні language bindings, які перетворюють API-виклики на WebDriver commands. Окремі команди підтримують Selenium project і browser vendors, тому version compatibility та відмінності bindings залишаються частиною експлуатації. Обидва інструменти — великі multi-language ecosystems. Вибір мови впливає не лише на синтаксис, а й на доступність runner integrations, fixtures, reporters, tracing і швидкість появи нових можливостей.
Згенерована `models.py` містить багато загальних класів на кшталт `Attributes1`, `Attributes2`, тому його краще використовувати як reference і поступово називати моделі за їхньою предметною роллю. Під час демо тест падає через неправильні imports і видалену fixture. Для circular import корисно читати останній змістовний фрейм traceback: там зазвичай вказано реальний модуль і напрям залежності. Якщо `pytest` не знаходить fixture, він друкує перелік усіх доступних fixtures, що допомагає помітити назву або проблему з discovery.
Після прискорення login cases нові fixtures пробують застосувати до решти suite. Для сценаріїв, яким уже потрібен авторизований користувач, planned fixture має один раз виконати login і віддати готову page. Для негативного login test, навпаки, потрібна неавторизована shared page. Автоматичний рефакторинг змінює більше тестів, ніж очікувалося, і частково плутає їх передумови. Це демонструє практичне правило: fixture називається за гарантованим станом (`anonymous_page`, `authenticated_page`), а migration робиться по одному behavior з повторним запуском, а не одним глобальним LLM-edit.
Перед комітом переглядаються видалені plugin parameters, custom fixtures, requirements і параметризовані cases. У підсумку кожна ітерація має читабельний ID, test data винесені з тіла сценарію, а browser reuse виконується через явний fixture graph. Практика після уроку — додати власні cases до таблиці, дати їм змістовні IDs, намалювати залежності fixtures і перевірити setup/teardown кожного scope. Окрема перевірка має довести, що попередня ітерація не залишає авторизацію або client-side state наступній.
Pytest fixture може мати scope `session`, `package`, `module`, `class` або `function`. Чим ширший scope, тим рідше створюється ресурс: session fixture — один раз на весь test run, function fixture — окремо для кожного тесту. Код до `yield` виконує setup, а після `yield` — teardown відповідного scope. Ціль уроку — перетворити один негативний login test на параметризований. Тіло сценарію залишається одним, а різні пари email/password та читабельні case IDs передаються як дані.