Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.
Перші версії fixture щоразу відкривають нову вкладку або неправильно закривають page. Реалізацію уточнюють так, щоб параметризовані cases працювали на тій самій page, але перед новою ітерацією очищали cookies і local storage та поверталися у відомий початковий стан. Простого `localStorage.clear()` недостатньо для універсальної ізоляції: стан також може бути в session storage, IndexedDB, service workers або server-side session. Тому shared context має сенс лише тоді, коли перелік станів відомий і cleanup перевірений. Новий `BrowserContext` залишається надійнішою межею ізоляції.