Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Офіційний 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, прараметризація тестів →Спроєктуй negative tests для читання чужого row, підміни owner claim, вставки row поза дозволеним scope та запиту на erasure з legal-retention exception. Відокрем authentication evidence, database authorization і data-lifecycle decision.
Набір cases показує, який шар відхиляє кожну дію та який audit evidence потрібен.
Apple API для asynchronous analysis live або prerecorded audio; transcription results надходять як sequence, locale assets керуються окремо, а analysis session має explicit finish/error lifecycle.
Корисні застосунки та їхнє призначення →Через custom fixture architecture у відео вручну інтегровано tracing і pytest hook.
Поточний pytest-playwright plugin підтримує --tracing retain-on-failure. Якщо тест використовує стандартні plugin fixtures, спершу варто перевірити цю option; custom hook потрібен, коли lifecycle контролюється власними fixtures.
Складіть однаковий список config keys для local, dev і CI без environment prefixes у коді.
Опишіть, хто створює test user, як він резервується для parallel worker і як відновлюється після failure.
Позначте зовнішні auth dependencies та окремо визначте production acceptance check і test-only seam.
Config matrix і state diagram без shared mutable user між parallel workers.
Після рефакторингу suite падає через змішування plugin-managed fixtures та вручну створеного sync Playwright instance. Додатково частина launch/context options дублюється в dictionary і кількох fixtures, що робить конфігурацію непослідовною. Рішення у відео — перейти на один спосіб володіння lifecycle: custom fixtures запускають Playwright і browser, а конфігурація збирається в одному місці. Частину pytest-playwright параметрів прибирають, бо custom launcher їх уже не читає. Загальний висновок: не можна одночасно очікувати, що plugin і власний код керуватимуть тим самим browser lifecycle.
Проєкт сам контролює `storage_state`, авторизовані та Free contexts, відкриття й закриття page. Через це готові fixtures плагіна не покривають потрібний lifecycle, а tracing доводиться інтегрувати у власний шар. Перед tracing виправляється побічна проблема: Free test відкривав два browser instances, бо вимагав fixture, результат якої не використовував. Видалення зайвої залежності прибирає другий запуск браузера.
Appium і WebdriverIO дають спільний зовнішній API для iOS та Android, але додають кілька шарів комунікації між тестом, Appium server, platform driver і device. Через це сценарії повільніші, а діагностика instability складніша, ніж у native tests. Одна бізнес-дія також може мати різний UI на різних платформах: date picker, введення числа, back navigation і переходи між екранами підпорядковуються різним design guidelines. Відрізняється й lifecycle: після згортання або повернення екран може відновити state з local storage чи повторно звернутися до backend. Спільний тест часто все одно отримує platform-specific branches або окремі page/screen objects.
Для middle і особливо senior рівня очікується розуміння типів даних, проходу collections, роботи з files та databases, object lifecycle, scope variables, initialization order і test runner lifecycle. Ці знання зазвичай закріплюються після реальної проблеми, а не після ізольованої лекції. Тому відповідь не вимірюється списком syntax topics. Junior має безпечно змінювати прості scripts; middle — діагностувати non-obvious behavior; senior — пояснювати system-level root cause й обирати правильний test seam.
Варто розуміти порядок, у якому test runner завантажує модулі, створює suite/test fixtures, запускає setup, test і teardown. Declaration задає ім'я та тип, assignment присвоює значення, а runtime initialization створює фактичний стан під час виконання програми. Точні терміни залежать від мови, але практичне питання однакове: коли ресурс уже існує й хто ним володіє. На співбесіді можуть попросити пояснити різницю між class та object, відрефакторити тест або написати надійний locator. Потрібно знати CSS/XPath настільки, щоб читати старий код, і віддавати перевагу user-facing locator API Playwright, коли семантична роль або label точніше виражає контракт.
Зайва сторінка з’явилася через те, що fixture створювала `context.new_page()` вдруге замість повернення вже авторизованої page. Після виправлення один context і одна page проходять увесь setup та test lifecycle. Друга помилка — інвертована умова `not exists`, через яку готовий state не використовувався. Перевірка маленьких умов, точного path і фактичного returned object часто швидше знаходить root cause, ніж повторний великий рефакторинг.
Перший критерій — уміти прибрати повторювану ручну роботу за прийнятну ціну. Це може бути Playwright, Cypress, Selenium, code generation або невеликий script будь-якою мовою. Важливіше отримати перевірюваний результат і feedback від сильнішого інженера, ніж одразу будувати «ідеальний framework». Глибоке знання мови стає потрібним, коли дефекти виникають на стиках: type conversion, concurrent requests, race conditions, database/file persistence, memory management, asynchronous behavior або lifecycle components. UI steps самі по собі цих причин не пояснюють.
[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.
Playwright MCP дозволяє моделі бачити й керувати сторінкою, але код генерує сама LLM. Однаковий prompt може дати різні структури, locators і helpers, тому інструкції не гарантують підтримуваний результат. Модель також не здогадається дослідити network, data lifecycle або project architecture, якщо це явно не поставлено завданням і не надано відповідний контекст.
Запис запускається через `context.tracing.start(screenshots=True, snapshots=True, sources=True)`, а перед закриттям context завершується `tracing.stop(path=...)`. Trace Viewer показує Playwright actions, DOM snapshots, source files і network. Якщо вставити start/stop у кожну низькорівневу fixture, код дублюється, а один session trace змішує кілька тестів. Tracing переноситься у test-scoped app fixtures, щоб кожен тест мав окремий lifecycle.