fixture scope
Межа кешування й teardown fixture: function, class, module, package або session. Залежність може використовувати fixture того самого або ширшого scope, але не вужчого.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
function-scoped fixture
function є default scope pytest fixture: fixture знищується наприкінці кожного тесту, який її використовує.
Окремий context для Free-користувача
Fixture створює isolated BrowserContext із наперед підготовленим Free-state; Enterprise-state має бути окремою fixture або parameterized input із чіткою очікуваною роллю.
Тест стартує у визначеному Free-контексті без умовного розгалуження за випадковим UI-станом.
На сторінці може бути різний контент — що робити? →Fixture scope
Pytest fixture зі scope session створюється один раз на test session, тому підходить для незмінної конфігурації всього запуску.
pytest fixture `page`
Fixture із pytest-playwright, яка надає ізольовану Playwright Page для тесту та прибирає ручне створення browser context у базовому сценарії.
yield fixture
pytest fixture виконує setup до yield, передає значення тесту, а cleanup після yield виконує під час teardown.
Fixture scopes і задача параметризації
Pytest fixture може мати scope `session`, `package`, `module`, `class` або `function`. Чим ширший scope, тим рідше створюється ресурс: session fixture — один раз на весь test run, function fixture — окремо для кожного тесту. Код до `yield` виконує setup, а після `yield` — teardown відповідного scope. Ціль уроку — перетворити один негативний login test на параметризований. Тіло сценарію залишається одним, а різні пари email/password та читабельні case IDs передаються як дані.
Синхронізація середовища та pytest fixture для Chrome
Після зміни залежностей запускається `uv sync`, а фактично встановлена версія звіряється з lock-файлом. Якщо імпорт не працює або підтягнулась неочікувана версія, спочатку треба перевірити синхронізацію середовища, а не змінювати тестовий код навмання. Створюється pytest fixture, яка ініціалізує `webdriver.Chrome()` і повертає driver тесту. Команди тесту надходять до browser driver, а він уже керує браузером. Аналогічно можна створювати Firefox, Edge або Safari driver, але для навчального сценарію достатньо Chrome. Сучасний Selenium Manager підбирає сумісний driver автоматично, тому за звичайного локального запуску не потрібно вручну завантажувати executable й прописувати шлях. Це спрощує fixture, але версії Selenium і браузера все одно мають залишатися відтворюваними в CI.
Fixtures як preconditions і postconditions
У двох тестах повторюється авторизація, тому з’являється fixture `login_user`. Fixture розглядається як механізм підготовки та, за потреби, очищення стану до/після тесту. Для логіну обирається scope `function`: підготовка виконується окремо перед кожним тестом, який явно запитує fixture. Це ізолює сценарії й не поширює авторизований стан на тести, яким він не потрібен.
Окрема fixture і виявлення прихованої залежності
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.
Передавання fixture в тести
Тест отримує `config` як параметр так само, як `page`. На цьому етапі fixture повертає dictionary, тому значення читаються за ключами: URL для відкриття сторінки, email і пароль для авторизації. Зміна проходить через реальний запуск тестів. Помилки на кшталт невірного імені fixture або відсутнього ключа знаходяться лише тоді, коли відповідний шлях справді виконується.
Мінімальний API client і pytest fixture
Клієнт містить лише потрібні операції: authentication і `get_projects`. У прикладі використано `httpx`, хоча для синхронного сценарію стандартний для проєкту HTTP-клієнт також достатній; не слід додавати dependency лише через згенерований AI-код. Авторизований client надається через pytest fixture. JWT кешується всередині instance, щоб кілька endpoint calls одного тестового lifecycle не повторювали login. Спочатку окремі API-тести перевіряють успішну авторизацію та непорожній список проєктів.
Явне підключення fixture і константа проєкту
Fixture додається параметром лише до двох сценаріїв, яким потрібен логін. Інший тест залишається без неї. Така явність показує залежності сценарію без прихованого глобального setup. Повторювана назва цільового проєкту переноситься в `TARGET_PROJECT` на рівні модуля. Це предметне значення, яке справді використовується в кількох місцях; окрема абстракція для одиничного рядка не створюється.
Перевикористання fixtures в інших тестах
Після прискорення login cases нові fixtures пробують застосувати до решти suite. Для сценаріїв, яким уже потрібен авторизований користувач, planned fixture має один раз виконати login і віддати готову page. Для негативного login test, навпаки, потрібна неавторизована shared page. Автоматичний рефакторинг змінює більше тестів, ніж очікувалося, і частково плутає їх передумови. Це демонструє практичне правило: fixture називається за гарантованим станом (`anonymous_page`, `authenticated_page`), а migration робиться по одному behavior з повторним запуском, а не одним глобальним LLM-edit.
Чому вбудованої pytest-playwright fixture недостатньо
Проєкт сам контролює `storage_state`, авторизовані та Free contexts, відкриття й закриття page. Через це готові fixtures плагіна не покривають потрібний lifecycle, а tracing доводиться інтегрувати у власний шар. Перед tracing виправляється побічна проблема: Free test відкривав два browser instances, бо вимагав fixture, результат якої не використовував. Видалення зайвої залежності прибирає другий запуск браузера.
Окремі `storageState` і suites для кожного контексту
Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.