function-scoped fixture
function є default scope pytest fixture: fixture знищується наприкінці кожного тесту, який її використовує.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Default pytest-playwright lifecycle уже reuse browser
Офіційний plugin тримає playwright, browser_type і browser на session scope, але context, page і new_context — на function scope. Shared context/page з уроку є custom ownership, а не default plugin fixture lifecycle.
2. Pytest fixtures, playwright fixture, прараметризація тестів →fixture scope
Межа кешування й teardown fixture: function, class, module, package або session. Залежність може використовувати fixture того самого або ширшого scope, але не вужчого.
2. Pytest fixtures, playwright fixture, прараметризація тестів →GraphQL resolver
Server-side function для schema field, яка отримує value з application code, database або downstream service. GraphQL не виконує service discovery самостійно.
Вступ до API-автоматизації →Playwright Pytest Plugin Reference
Підтверджує session-scoped browser і function-scoped context/page fixtures.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗Type hint
Python runtime не примушує function і variable annotations відповідати значенням; annotations споживають type checkers, IDE та інші tools.
4. Типізація даних (str, int, float, bool) →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 передаються як дані.
Вкладені функції та scope
Функцію можна оголосити всередині іншої, тоді вона доступна лише в зовнішньому function body. Це інколи допомагає розкласти великий transform, але single-use nested helper не завжди покращує код. Якщо логіка потрібна в кількох місцях, її краще зробити звичайною module-level function із чітким контрактом.
Оголошення і виклик функції
Саме оголошення `def print_hello():` нічого не виконує. Функцію треба окремо викликати. Це розділяє опис поведінки та момент її запуску. Далі функція параметризується ім’ям. Замість фіксованого `Hello World` вона приймає `name` і формує `f"Hello {name}"`, тому один алгоритм працює з різними вхідними даними.
Fixtures як preconditions і postconditions
У двох тестах повторюється авторизація, тому з’являється fixture `login_user`. Fixture розглядається як механізм підготовки та, за потреби, очищення стану до/після тесту. Для логіну обирається scope `function`: підготовка виконується окремо перед кожним тестом, який явно запитує fixture. Це ізолює сценарії й не поширює авторизований стан на тести, яким він не потрібен.
Від 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.
DRY: допоміжні функції без прихованих даних
Коли логін повторився у двох тестах, його винесено у `login_user(page, email, password)`. Дані не хардкодяться всередині helper-функції: тест передає `Page`, email і пароль явно. Type hints допомагають IDE підказувати доступні операції та помічати неправильні аргументи ще до запуску. Так само через Extract Method створюється `open_home_page(page)`. Допоміжні функції розміщуються нижче тестів, щоб під час code review спочатку читалися сценарії, а вже потім технічні деталі.
Списки цін, `max()` і читабельна перевірка
Кілька цін збираються в типізований список, наприклад `list[float]`. `max(prices)` знаходить найбільше значення, а перший елемент можна порівняти з ним, щоб перевірити сортування «від більшої ціни». Навіть коротку, але предметно важливу логіку пропонується оформити функцією на кшталт `is_first_price_highest(prices)`. Назва пояснює вимогу краще, ніж вкладене порівняння всередині великого тесту.
Швидкість, rate limit і межі reuse
Після прямої навігації та reuse page параметризований тест виконується швидше, але все одно впирається в rate limit. У демонстрації додається двосекундна пауза. Це придатна тимчасова діагностика, але стабільне рішення має узгодити навантаження з test environment: контрольовані test accounts, documented quota, backoff або окремий seam для form validation. Наприкінці ще раз простежується lifecycle: browser може жити всю session, context — module або function, page — відповідно до вимог тесту. Чим довше живе ресурс, тим вища швидкість і тим більший ризик state leakage. Scope обирають не за принципом «найширший = найкращий», а за найдовшою безпечною межею.