BrowserContext.add_cookies
Метод додає cookies до context; кожна його page отримує ці cookies, а cookie задається через url або пару domain і path.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
storageState охоплює більше, ніж cookies і localStorage
У відео сценарій побудований навколо cookies, storage state та companyId для вибору ролі.
Актуальний API також уміє включати IndexedDB через indexed_db (додано у v1.51) і virtual WebAuthn credentials через credentials (додано у v1.61).
На сторінці може бути різний контент — що робити? →Authenticated browser state
Збережені cookies і headers для повторного використання авторизованої browser session. Такий файл може дозволити impersonation test account, тому його не слід комітити навіть у private repository; shared account підходить лише для tests без конфліктних server-side mutations.
Практика курсу на YOY, домашні завдання та формат ПМП →Authentication state є секретом
State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.
На сторінці може бути різний контент — що робити? →BrowserContext
Ізольоване browser profile у Playwright. Playwright Test створює окремий context для кожного test, ізолюючи cookies, local storage і session storage.
Що має вміти та знати мідл автоматизатор →BrowserContext
Ізольоване браузерне середовище Playwright. Окремі contexts не ділять cookies та інший стан, що підтримує відтворюваність тестів.
На сторінці може бути різний контент — що робити? →Як знайти керівний стан у DevTools
Щоб зрозуміти, чому UI різниться, потрібно дивитися не лише на сторінку. У DevTools варто перевірити `Network`, cookies, `localStorage` і `sessionStorage` та знайти дані, які визначають активну компанію або роль. У прикладі різницю задає `companyId`: конкретний ID відкриває корпоративний контекст, а відсутнє значення — free-проєкти. Це дає точну підказку, який стан треба підготувати перед тестом.
Cookie helper для feature flags
Cookies корисні не лише для авторизації. Вони можуть увімкнути feature flag, направити автоматизований трафік на окремий backend або задати тестовий режим на спільному домені. Маніпуляцію варто сховати в короткий helper/decorator над `BrowserContext`: тест передає `name`, `value`, `domain` і `path`, а helper додає cookie. Domain має точно охоплювати потрібний host; після зміни зазвичай треба reload сторінки, щоб наступні запити та UI підхопили нове значення.
Створення state для Free plan
Перший варіант дублює Enterprise state й через стандартний модуль `json` очищає cookie `Company ID`. Пошук проходить масив cookies, змінює лише елемент із потрібним `name` і записує окремий файл. Цей підхід є оптимізацією для конкретного застосунку, а не універсальним правилом Playwright. Якщо backend session або інший state також прив’язаний до tenant, безпечніше реально перемкнути проєкт у браузері й зберегти отриманий context.
Shared page та очищення стану
Перші версії fixture щоразу відкривають нову вкладку або неправильно закривають page. Реалізацію уточнюють так, щоб параметризовані cases працювали на тій самій page, але перед новою ітерацією очищали cookies і local storage та поверталися у відомий початковий стан. Простого `localStorage.clear()` недостатньо для універсальної ізоляції: стан також може бути в session storage, IndexedDB, service workers або server-side session. Тому shared context має сенс лише тоді, коли перелік станів відомий і cleanup перевірений. Новий `BrowserContext` залишається надійнішою межею ізоляції.
DOM breakpoints і практична перевірка cookies
Альтернативний спосіб — DevTools breakpoint `Break on subtree modifications` на контейнері. Після Save браузер зупиниться на зміні DOM; покрокове продовження дозволяє знайти проміжні стани `Saving` і `Saved` та побудувати locator. Для перевірки cookie тест ставиться на паузу, у DevTools відкривається Application → Cookies, виконується наступний крок і reload. Так видно, що feature flag дійсно додано до правильного домену до того, як на нього покладатиметься assertion.
Навіщо перевикористовувати авторизацію
Повторний login у кожному тесті витрачає час і збільшує кількість нестабільних UI-кроків. Playwright може зберегти cookies та local storage після однієї авторизації, а нові browser contexts стартуватимуть уже в потрібному стані. Таке спільне використання допустиме лише тоді, коли застосунок дозволяє паралельні сесії одного акаунта, а тести не змінюють взаємно залежний server-side стан. `storage state` прибирає login, але не робить інші дані тестів незалежними.
Рольова модель як кандидат для окремих states
Якщо функціональність залежить від ролі, тарифу або tenant, тести доцільно групувати за відповідним станом користувача. У прикладі один акаунт має доступ до Enterprise і Free проєктів, але в реальній системі це можуть бути окремі користувачі. Перед реалізацією досліджується UI, Network, cookies та local storage. Перемикання проєкту змінює `Company ID`; додатковими спостережуваними ознаками є тексти `Enterprise subscription` і `Free subscription`.
Окремі `storageState` і suites для кожного контексту
Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.
Завантаження `storage_state` у новий context
Самого запису state недостатньо: шлях треба передати в `browser.new_context(storage_state=...)`. Browser options збираються у dictionary, який доповнюється лише тоді, коли шлях передано і файл існує. Урок порівнює два JSON states після перемикання проєкту. Окрім `Company ID`, можуть змінюватися timestamps, analytics cookies і backend session, тому ручне припущення про «єдину різницю» треба перевіряти, а не приймати наперед.
Де й у якому форматі зберігати state
Playwright записує state як JSON із cookies та origins/local storage. Cookie містить `name`, `value`, `domain`, `path`, expiration, `httpOnly`, `secure` та інші параметри; новий context отримує цей файл через `storage_state`. Файл не можна комітити: він може містити чинну сесію та дані внутрішньої інфраструктури. У прикладі state лежить у вже заігнореній `test-results`; окрема директорія також прийнятна, якщо вона гарантовано додана до `.gitignore`.