Python мануфактураJavaDesign Patterns для автоматизаторів

Python мануфактура · Програма курсу · 0:00–3:45

Рольова модель як кандидат для окремих states

Якщо функціональність залежить від ролі, тарифу або tenant, тести доцільно групувати за відповідним станом користувача. У прикладі один акаунт має доступ до Enterprise і Free проєктів, але в реальній системі це можуть бути окремі користувачі. Перед реалізацією досліджується UI, Network, cookies та local storage. Перемикання проєкту змінює `Company ID`; додатковими спостережуваними ознаками є тексти `Enterprise subscription` і `Free subscription`.

2.1. Storage state: практична реалізація, фікстури для ролей →

Python мануфактура · Програма курсу · 0:00–5:35

Навіщо перевикористовувати авторизацію

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

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

Python мануфактура · Сесії: AMA та PMP · 2:55–5:45

Окремі `storageState` і suites для кожного контексту

Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.

На сторінці може бути різний контент — що робити? →

Python мануфактура · Програма курсу · 5:45–9:55

`yield` і життєвий цикл context

Fixture створює context, завантажує готовий state або виконує login і записує його, після чого віддає page через `yield`. Код після `yield` є teardown і закриває page/context. Важливо повертати вже створену page, а не викликати `new_page()` ще раз. Так test actions, trace і cleanup належать одному browser context.

4. Повертаємо traces, pytest hooks, рефакторинг дублювань у fixtures →

Python мануфактура · Програма курсу · 30:45–35:55

`get_or_create_context` без дублювання

Звичайний і Free flows дублювали перевірку state path, options для `new_context`, login та повернення page. Спільна функція `get_or_create_context` будує context і повідомляє, чи потрібна авторизація. Верхні fixtures залишають предметні кроки: звичайна зберігає авторизований state; Free додатково перемикає проєкт і зберігає Free state. Спільний helper не повинен поглинати ці відмінності лише заради меншої кількості рядків.

4. Повертаємо traces, pytest hooks, рефакторинг дублювань у fixtures →
Запитати в чаті про «storage-state» →