yield fixture
pytest fixture виконує setup до yield, передає значення тесту, а cleanup після yield виконує під час teardown.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
pytest fixtures
Підтверджує й актуалізує поняття уроку, пов’язані з yield fixture.
2.1. Storage state: практична реалізація, фікстури для ролей → Першоджерело ↗Fixture для Free state з коректним teardown
Віддає одну page з окремого state й гарантовано закриває весь context після тесту.
Тест отримує page у Free state, а context закривається під час teardown.
2.1. Storage state: практична реалізація, фікстури для ролей →Збереження reports на pytest node
Зберігає reports фаз у typed pytest stash, щоб teardown fixture могла перевірити failure потрібної фази.
Після фази call item.stash[phase_reports_key]["call"] містить відповідний TestReport.
Окремий context для Free-користувача
Fixture створює isolated BrowserContext із наперед підготовленим Free-state; Enterprise-state має бути окремою fixture або parameterized input із чіткою очікуваною роллю.
Тест стартує у визначеному Free-контексті без умовного розгалуження за випадковим UI-станом.
На сторінці може бути різний контент — що робити? →`yield` і життєвий цикл context
Fixture створює context, завантажує готовий state або виконує login і записує його, після чого віддає page через `yield`. Код після `yield` є teardown і закриває page/context. Важливо повертати вже створену page, а не викликати `new_page()` ще раз. Так test actions, trace і cleanup належать одному browser context.
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 передаються як дані.
Fallback для чистого запуску
Fallback будує context, створює page, авторизується, переходить до Free проєкту й записує `storage_state`. Після цього та сама page передається тесту через `yield`, щоб сценарій продовжився без повторного відкриття вкладки. Під час демонстрації код кілька разів дублюється для швидкої перевірки, а потім уточнюється. Ключовий критерій — окремий Free test має проходити самостійно після видалення всіх локальних state-файлів.
`pytest_runtest_makereport` і фази виконання
Fixture не знає результат тесту напряму, тому `conftest.py` підключає hook `pytest_runtest_makereport`. Hook отримує звіт для кожної фази та записує його в атрибут node, наприклад `rep_setup`, `rep_call`, `rep_teardown`. Для assertion failure самого тесту перевіряється `request.node.rep_call.failed`. `setup` охоплює код до `yield`, `call` — тіло тесту, `teardown` — код після `yield`. Якщо потрібно зберігати trace також при fixture setup failure, це окреме розширення контракту; демонстрація фокусується на `call`.
Від plugin fixtures до власного життєвого циклу
Стандартні pytest-playwright fixtures добре ізолюють тести: нові context/page створюються автоматично, а cleanup виконує plugin. Для великої таблиці негативних логінів це створює помітні накладні витрати, тому у відео будується власний lifecycle: один Playwright/browser instance на ширший scope і спеціальні fixtures для clean app, logged-in app та shared page. Ключова ієрархія залежностей: Playwright instance запускає browser; browser створює context; context створює page. Scope залежної fixture не може бути ширшим за ресурс, від якого вона залежить. `yield` повинен закрити рівно ті ресурси, які fixture створила. Це optimization з ціною: повторне використання page/context послаблює ізоляцію. Починати безпечніше зі стандартних function-scoped fixtures, а reuse додавати лише після виміряного bottleneck і разом із перевіреним cleanup.