Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Видаліть локальні state-файли.
Запустіть лише один Free test і перевірте створення state через fallback.
Запустіть той самий тест вдруге й перевірте повторне використання state без другої page.
Обидва запуски проходять окремо; перший створює state, другий його використовує, одночасно відкрита одна page.
Віддає одну page з окремого state й гарантовано закриває весь context після тесту.
Тест отримує page у Free state, а context закривається під час teardown.
2.1. Storage state: практична реалізація, фікстури для ролей →У відео рекомендовано API preconditions, reused authenticated state та незалежні test data.
Поточна документація Playwright рекомендує не комітити auth state і використовувати окремий account на parallel worker, якщо tests змінюють shared server-side state. Конкретні fixtures, directories та worker APIs слід звіряти з версією Playwright у проєкті.
Практика курсу на YOY, домашні завдання та формат ПМП →Fixture створює isolated BrowserContext із наперед підготовленим Free-state; Enterprise-state має бути окремою fixture або parameterized input із чіткою очікуваною роллю.
Тест стартує у визначеному Free-контексті без умовного розгалуження за випадковим UI-станом.
На сторінці може бути різний контент — що робити? →Пояснює ізоляцію BrowserContext, повторне використання auth state та ризик витоку state-файлів.
На сторінці може бути різний контент — що робити? → Першоджерело ↗Створює context із готовою авторизацією та додає тестовий cookie до переходу на сторінку.
Запити page до example.test містять feature cookie; auth залежить від локального state-файлу.
Playwright записує state як JSON із cookies та origins/local storage. Cookie містить `name`, `value`, `domain`, `path`, expiration, `httpOnly`, `secure` та інші параметри; новий context отримує цей файл через `storage_state`. Файл не можна комітити: він може містити чинну сесію та дані внутрішньої інфраструктури. У прикладі state лежить у вже заігнореній `test-results`; окрема директорія також прийнятна, якщо вона гарантовано додана до `.gitignore`.
Звичайний і Free flows дублювали перевірку state path, options для `new_context`, login та повернення page. Спільна функція `get_or_create_context` будує context і повідомляє, чи потрібна авторизація. Верхні fixtures залишають предметні кроки: звичайна зберігає авторизований state; Free додатково перемикає проєкт і зберігає Free state. Спільний helper не повинен поглинати ці відмінності лише заради меншої кількості рядків.
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
Самого запису state недостатньо: шлях треба передати в `browser.new_context(storage_state=...)`. Browser options збираються у dictionary, який доповнюється лише тоді, коли шлях передано і файл існує. Урок порівнює два JSON states після перемикання проєкту. Окрім `Company ID`, можуть змінюватися timestamps, analytics cookies і backend session, тому ручне припущення про «єдину різницю» треба перевіряти, а не приймати наперед.
Перший варіант дублює Enterprise state й через стандартний модуль `json` очищає cookie `Company ID`. Пошук проходить масив cookies, змінює лише елемент із потрібним `name` і записує окремий файл. Цей підхід є оптимізацією для конкретного застосунку, а не універсальним правилом Playwright. Якщо backend session або інший state також прив’язаний до tenant, безпечніше реально перемкнути проєкт у браузері й зберегти отриманий context.
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.
У banking та інших регульованих доменах onboarding може проходити довгий Business Process Management flow з compliance-перевірками. Одна сутність не завжди може одночасно рухатися двома переходами стану, тому паралельні тести на спільному профілі конфліктують або блокують processing. Для стабільної автоматизації потрібно знати state machine, зовнішні залежності та правила блокування. Якщо динамічне створення неможливе, керований pool тестових сутностей має враховувати їх поточний стан, reservation, recovery після падіння тесту та регулярне відновлення після refresh середовища.
Повторний login у кожному тесті витрачає час і збільшує кількість нестабільних UI-кроків. Playwright може зберегти cookies та local storage після однієї авторизації, а нові browser contexts стартуватимуть уже в потрібному стані. Таке спільне використання допустиме лише тоді, коли застосунок дозволяє паралельні сесії одного акаунта, а тести не змінюють взаємно залежний server-side стан. `storage state` прибирає login, але не робить інші дані тестів незалежними.
Fixture створює context, завантажує готовий state або виконує login і записує його, після чого віддає page через `yield`. Код після `yield` є teardown і закриває page/context. Важливо повертати вже створену page, а не викликати `new_page()` ще раз. Так test actions, trace і cleanup належать одному browser context.
Page Object збирає технічні дії у предметні кроки авторизації. Перед введенням він чекає готовність полів, після Sign in — очікуваний success state. Це робить тест коротшим, але не приховує важливі переходи стану. Для параметризованих негативних login cases кожен приклад має стартувати з контрольованого стану. Інакше message, що з’явився після першої спроби, може залишитися для наступної та дати false positive. Залежно від продукту потрібні нова сторінка, refresh або явне очищення стану. Повернення `self` з кожного `click()` чи `type_text()` дозволяє chaining, але урок ставиться до цього обережно: ланцюжок не повинен створювати операції, які предметно не мають сенсу. Читабельна окрема дія часто краща за універсальний fluent interface.