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

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 · 4:40–9:10

Channel, transport та ієрархія browser objects

[Дивитися з 04:40](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=280s). Перехід у реалізацію `click()` показує виклик на кшталт `channel.send(...)`: назва команди та її parameters передаються нижчому шару. Далі досліджується ієрархія об’єктів: `Browser` створює `BrowserContext`, context містить `Page`, а page працює з frames і locators. Python- і Java-клієнти не реалізують browser automation незалежно від основного Playwright driver. Вони формують команди та обмінюються повідомленнями з driver process через transport. Саме тому package містить platform-specific executable, а public API різних мов лишається концептуально подібним.

Як Playwright взаємодіє з браузером через протокол →

Python мануфактура · Програма курсу · 12:45–16:40

Cookie helper для feature flags

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

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

Python мануфактура · Програма курсу · 26:00–34:00

Ієрархія Playwright і запуск test suites

У спрощеній моделі Playwright спочатку запускає browser process, потім створює ізольований `BrowserContext`, а в ньому — одну або кілька `Page`. Launch options стосуються процесу браузера, context options — сесії користувача, cookies, permissions та емуляції, а `Page` представляє вкладку й виконує дії зі сторінкою. Через `channel="chrome"` можна запустити встановлений branded Chrome замість bundled Chromium. Це потрібно, коли поведінка залежить від повного браузера або медіакодеків; для більшості перевірок швидшого bundled Chromium достатньо. Маркери дають змогу виконувати `smoke` і `regression` окремо. Практичний CI flow: спочатку короткий smoke suite перевіряє, що середовище придатне до тестування, і лише після нього запускається довша regression suite.

1. Налаштування Playwright та Pytest, простий репортінг →

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 →

Python мануфактура · Програма курсу · 31:35–38:20

Усунення другої сторінки та інвертованої умови

Зайва сторінка з’явилася через те, що fixture створювала `context.new_page()` вдруге замість повернення вже авторизованої page. Після виправлення один context і одна page проходять увесь setup та test lifecycle. Друга помилка — інвертована умова `not exists`, через яку готовий state не використовувався. Перевірка маленьких умов, точного path і фактичного returned object часто швидше знаходить root cause, ніж повторний великий рефакторинг.

2.1. Storage state: практична реалізація, фікстури для ролей →
Запитати в чаті про «browser-context» →