Anatomy of a test
Підтверджує й актуалізує поняття уроку: Arrange, Act, Assert, Cleanup.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Arrange–Act–Assert
Pytest описує тест як послідовність підготовки стану, однієї цільової дії, перевірки результату та, за потреби, cleanup.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →Playwright: Isolation
Межа BrowserContext і ризики cleanup-based isolation.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗yield fixture
pytest fixture виконує setup до yield, передає значення тесту, а cleanup після yield виконує під час teardown.
Вибрати правильний test seam для persistence
Для одного business flow перелічіть validation, events, audit і data transformations між API та database.
Визначте, які properties доводить unit, integration та end-to-end test.
Якщо direct DB setup залишається, задайте connection ownership, transaction boundary і cleanup для parallel workers.
Test matrix без дублювання framework behavior і з явним direct-DB ceiling.
Перевірка fixture isolation
Створіть параметризовані negative login cases з IDs.
Запустіть їх із function-scoped BrowserContext.
Окремо спробуйте shared page із явним cleanup.
Додайте check, що authorization state попередньої ітерації не доступний наступній, і порівняйте час запуску.
Є вимірювання speed trade-off і test, який падає при state leakage.
`finally` для cleanup
`finally` виконується незалежно від успіху або exception. Це місце для закриття database connection, file handle чи іншого обмеженого ресурсу. У прикладі timeout query обробляється, але connection усе одно закривається, щоб не вичерпати pool під навантаженням.
`yield` і життєвий цикл context
Fixture створює context, завантажує готовий state або виконує login і записує його, після чого віддає page через `yield`. Код після `yield` є teardown і закриває page/context. Важливо повертати вже створену page, а не викликати `new_page()` ще раз. Так test actions, trace і cleanup належать одному browser context.
Від 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.
`TemporaryDirectory` і `Path`
`with TemporaryDirectory() as tmp_dir` створює ізольовану directory та автоматично видаляє її після виходу з context manager. `Path(tmp_dir) / "test-result.txt"` будує platform-safe path. Тому файл доступний усередині блоку, але закономірно зникає після завершення операції.
Комбінований UI/API/DB framework і архітектурний рівень
Framework, який одночасно керує UI, API та DB, вимагає чітких lifecycle і ownership: окремі clients, ізольовані test data, безпечний connection pool, cleanup і коректна робота в parallel. Додавати всі рівні до кожного тесту не потрібно; кожен сценарій має використовувати найнижчий seam, який доводить потрібну поведінку. На senior-рівні додаються system architecture, protocols, caching і concurrency. В event-driven системах доводиться спостерігати Kafka, RabbitMQ або інший broker, чекати eventual consistency та корелювати події. Stub service корисний для контрольованих failure/edge cases, але не замінює невеликий набір справжніх integration tests.
Незалежні користувачі, cleanup і цілісність даних
Спільний тестовий користувач створює race conditions: паралельні тести змінюють один стан, заважають один одному й роблять результат нестабільним. Найкращий шов — створювати унікального користувача або іншу сутність під конкретний тест чи worker. Фізичне видалення даних може зламати foreign keys та історичні зв'язки з orders, invoices або іншими сутностями. Через це продукт часто застосовує soft delete: запис залишається, але отримує статус deleted/inactive. Для тестових середовищ потрібно знати реальну політику refresh/cleanup; не слід бездумно накопичувати персональні production-дані або копіювати їх без маскування й визначеного строку зберігання.
Паралельні задачі, merge і видалення гілок
Якщо задачу треба відкласти, достатньо повернутися на `main`; її коміти залишаються у власній гілці. Після завершення та схвалення зміни гілка зливається відповідно до правил репозиторію. У сольній демонстрації показано локальний merge у `main` і подальший push. У командному проєкті джерелом правил є захищена гілка та PR workflow: не слід обходити review локальним merge. Після успішного merge локальну й remote-гілку можна видалити — коміти залишаються в історії.
Shared page та очищення стану
Перші версії fixture щоразу відкривають нову вкладку або неправильно закривають page. Реалізацію уточнюють так, щоб параметризовані cases працювали на тій самій page, але перед новою ітерацією очищали cookies і local storage та поверталися у відомий початковий стан. Простого `localStorage.clear()` недостатньо для універсальної ізоляції: стан також може бути в session storage, IndexedDB, service workers або server-side session. Тому shared context має сенс лише тоді, коли перелік станів відомий і cleanup перевірений. Новий `BrowserContext` залишається надійнішою межею ізоляції.
Fallback для чистого запуску
Fallback будує context, створює page, авторизується, переходить до Free проєкту й записує `storage_state`. Після цього та сама page передається тесту через `yield`, щоб сценарій продовжився без повторного відкриття вкладки. Під час демонстрації код кілька разів дублюється для швидкої перевірки, а потім уточнюється. Ключовий критерій — окремий Free test має проходити самостійно після видалення всіх локальних state-файлів.
Швидкість, 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 обирають не за принципом «найширший = найкращий», а за найдовшою безпечною межею.