Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Ручне очищення cookies і local storage не дорівнює новому BrowserContext. Якщо reuse справді потрібен після вимірювання, fixture повинна мати явний contract стану й окрему regression check на leakage.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Офіційний plugin тримає playwright, browser_type і browser на session scope, але context, page і new_context — на function scope. Shared context/page з уроку є custom ownership, а не default plugin fixture lifecycle.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Після прямої навігації та reuse page параметризований тест виконується швидше, але все одно впирається в rate limit. У демонстрації додається двосекундна пауза. Це придатна тимчасова діагностика, але стабільне рішення має узгодити навантаження з test environment: контрольовані test accounts, documented quota, backoff або окремий seam для form validation. Наприкінці ще раз простежується lifecycle: browser може жити всю session, context — module або function, page — відповідно до вимог тесту. Чим довше живе ресурс, тим вища швидкість і тим більший ризик state leakage. Scope обирають не за принципом «найширший = найкращий», а за найдовшою безпечною межею.
`build_login_payload(email, password)` централізує структуру request body й прибирає дублювання inline dictionaries. Назва має описувати одну дію, а повернений об’єкт можна використати в кількох тестах. Секрети не слід виводити в logs навіть у допоміжних функціях.
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
Стандартні 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.
Перед комітом переглядаються видалені plugin parameters, custom fixtures, requirements і параметризовані cases. У підсумку кожна ітерація має читабельний ID, test data винесені з тіла сценарію, а browser reuse виконується через явний fixture graph. Практика після уроку — додати власні cases до таблиці, дати їм змістовні IDs, намалювати залежності fixtures і перевірити setup/teardown кожного scope. Окрема перевірка має довести, що попередня ітерація не залишає авторизацію або client-side state наступній.