2. Storage state, cookie manipulation, дебаг зникаючих елементів

Повторний login у кожному тесті витрачає час і збільшує кількість нестабільних UI-кроків. Playwright може зберегти cookies та local storage після однієї авторизації, а нові browser contexts стартуватимуть уже в потрібному стані.

Таке спільне використання допустиме лише тоді, коли застосунок дозволяє паралельні сесії одного акаунта, а тести не змінюють взаємно залежний server-side стан. storage state прибирає login, але не робить інші дані тестів незалежними.

context = browser.new_context(storage_state="playwright/.auth/user.json")
context.add_cookies([{
    "name": "feature_enabled",
    "value": "1",
    "url": "https://example.test",
}])
page = context.new_page()
page.goto("https://example.test")

Один conftest.py накопичив конфігурацію, запуск браузера, створення сторінки й app-specific fixtures. Код розділяється на модулі config, playwright та app, а кореневий conftest.py лише підключає їх через pytest_plugins.

Технічний шар створює браузер і context; app-шар виконує login, перевіряє, що цільова сторінка завантажена, і зберігає state. Такий поділ залишає місце для Firefox або інших browser options без змішування з бізнесовими переходами.

Після переходу на uv набори запускаються через uv run pytest і pytest markers на кшталт smoke або regression. Перший context виконує login та записує state, наступні contexts завантажують цей файл.

Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний is_loaded або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.

Cookies корисні не лише для авторизації. Вони можуть увімкнути feature flag, направити автоматизований трафік на окремий backend або задати тестовий режим на спільному домені.

Маніпуляцію варто сховати в короткий helper/decorator над BrowserContext: тест передає name, value, domain і path, а helper додає cookie. Domain має точно охоплювати потрібний host; після зміни зазвичай треба reload сторінки, щоб наступні запити та UI підхопили нове значення.

Playwright записує state як JSON із cookies та origins/local storage. Cookie містить name, value, domain, path, expiration, httpOnly, secure та інші параметри; новий context отримує цей файл через storage_state.

Файл не можна комітити: він може містити чинну сесію та дані внутрішньої інфраструктури. У прикладі state лежить у вже заігнореній test-results; окрема директорія також прийнятна, якщо вона гарантовано додана до .gitignore.

page.pause() зупиняє тест і відкриває Playwright Inspector. Це дає змогу подивитися поточний DOM, перевірити locator та виконувати кроки по одному, не покладаючись лише на звичайний debugger IDE.

Для короткоживучого статусу на кшталт Saving/Saved треба поставити паузу одразу після дії, яка його породжує. Якщо елемент зникає надто швидко, DevTools Sources може призупинити JavaScript через F8.

Альтернативний спосіб — DevTools breakpoint Break on subtree modifications на контейнері. Після Save браузер зупиниться на зміні DOM; покрокове продовження дозволяє знайти проміжні стани Saving і Saved та побудувати locator.

Для перевірки cookie тест ставиться на паузу, у DevTools відкривається Application → Cookies, виконується наступний крок і reload. Так видно, що feature flag дійсно додано до правильного домену до того, як на нього покладатиметься assertion.