Playwright Isolation
Описує per-test BrowserContext і межу client-side isolation.
Що має вміти та знати мідл автоматизатор → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Playwright: Isolation
Межа BrowserContext і ризики cleanup-based isolation.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗Playwright Test Isolation
Підтверджує й актуалізує поняття уроку, пов’язані з test isolation.
2.1. Storage state: практична реалізація, фікстури для ролей → Першоджерело ↗Self-hosted runner не є isolation boundary
GitHub попереджає, що код workflow на self-hosted runner може скомпрометувати машину та доступні secrets. Один runner виконує одну job одночасно, але це не гарантує ізоляцію між послідовними jobs; для untrusted workflows потрібні ephemeral runners або інша isolation strategy.
Інфраструктура автотестів та її нюанси →Browser-test contract
Playwright рекомендує user-visible behavior, isolation, контроль тестових даних і відмову від прямої залежності від неконтрольованих third-party systems.
Піраміда тестування, чому не API спочатку та як жити з упровадженням ШІ →Create custom subagents
Документує current Claude Code custom subagent schema, context isolation і execution modes.
Як налаштувати мультиагентне середовище → Першоджерело ↗Локальні пакети й ізоляція проєктів
Мови й екосистеми мають власні package managers або build tools: pip, npm, Maven, Gradle та інші. Вони завантажують бібліотеки з центральних репозиторіїв і можуть кешувати їх локально, але залежності конкретного проєкту визначаються окремо. Python virtual environment ізолює бібліотеки одного проєкту від іншого. На одному комп’ютері можуть співіснувати робочі й особисті репозиторії з різними версіями Playwright, pytest та інших пакетів. Конфлікт можливий, якщо запустити код не тим глобальним Python або неправильно вибрати interpreter. Самі залежності коректно створених `venv` не повинні впливати на сусідні проєкти.
Незалежні тести, test design і участь у плануванні
Тести мають бути незалежними за даними та станом. Залежна послідовність інколи може з'явитися як швидка перша ітерація, але це технічний борг: окремий тест не можна надійно повторити, а suite важче паралелити й діагностувати. Automation engineer не звільняється від базових QA-навичок: decomposition, impact analysis, risk assessment і test-design techniques. Межа між manual та automation розмивається, але повний перехід лише в один тип роботи атрофує іншу частину навичок. Участь на ранній фазі refinement допомагає заздалегідь визначити testability та потрібний рівень покриття.
Запуск suites і межі повторного state
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
Стратегії селекторів і контроль стану
CSS-селектори залишаються основним варіантом. XPath потрібен у Selenium для окремих випадків пошуку за текстом або зв’язком parent/child, але швидко ускладнюється: видимий текст може бути розбитий між кількома DOM-вузлами. Стійкі `data-testid`, `id` або `name` краще узгодити з frontend-командою, ніж будувати крихкий XPath навколо layout. Це не «деталь тестів», а тестований контракт між UI та автоматизацією. Рекомендований у відео компроміс: Page Object зберігає locator tuples, а спільні `click`/`type` helpers автоматично чекають релевантний стан. Поряд із цим кожен тест повинен відновлювати потрібний стан, бо локальний success не гарантує стабільність у повному suite.
Окрема fixture і виявлення прихованої залежності
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.
Унікальні test data і повторне використання slug
[Дивитися з 23:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1380s). Автотест не може покладатися на випадкове ручне очищення: кожен run потребує незалежних names, emails та URLs, наприклад через Faker або контрольований unique suffix. Водночас validation tests мають використовувати стабільний набір навмисно невалідних values. Обговорення виявляє можливий defect: після soft delete database identity може лишатися, але public slug доцільно анонімізувати або звільняти, якщо зовнішні зв’язки тримаються за immutable ID.
Shared page та очищення стану
Перші версії fixture щоразу відкривають нову вкладку або неправильно закривають page. Реалізацію уточнюють так, щоб параметризовані cases працювали на тій самій page, але перед новою ітерацією очищали cookies і local storage та поверталися у відомий початковий стан. Простого `localStorage.clear()` недостатньо для універсальної ізоляції: стан також може бути в session storage, IndexedDB, service workers або server-side session. Тому shared context має сенс лише тоді, коли перелік станів відомий і cleanup перевірений. Новий `BrowserContext` залишається надійнішою межею ізоляції.