Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Візьміть реальну browser analytics або письмову support policy продукту.
Позначте scenarios, які достатньо виконувати в Chromium/Firefox/WebKit.
Окремо позначте browser/vendor requirements, що потребують Selenium/Grid або cloud provider.
Запишіть очікувану topology, latency risks і мінімальний cross-browser suite.
Є коротке рішення Playwright-only або Playwright+Selenium, пов'язане з виміряною browser matrix, а не з популярністю інструмента.
У відео пояснено, що package version у requirements не гарантує наявність потрібного browser binary.
Актуальна документація підтверджує version-specific browser binaries і прямо зазначає, що після Playwright update може знадобитися повторний install CLI.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Офіційний 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, прараметризація тестів →Відкриває browser та Inspector для запису flow; target Python/pytest обирається в Inspector.
Відкриваються browser і Inspector, а interactions з’являються як generated code.
4. Playwright плагіни та codegen →Ізольований browser session між Browser і Page, у контексті якого створюються сторінки та налаштовується їхня поведінка.
Мінімальна послідовність для browser tests у CI: checkout, Python/dependency setup, встановлення browser dependencies, запуск pytest і збереження diagnostic artifact.
2. Практика та написання пайплану CI/CD →Коли одночасно використовуються персональні, робочі й client accounts, відкриття link у default browser може змішати sessions або показати не той account під час screen sharing. Автор розділяє контексти через різні browser profiles і навіть різні browsers. Browser Kitty перехоплює відкриття URL та дозволяє keyboard shortcut-ом вибрати потрібний browser, profile, desktop app або incognito mode. Практичний результат — менше ручних переходів і нижчий ризик випадково відкрити приватний або робочий ресурс у неправильному контексті.
[Дивитися з 09:10](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=550s). Для `click`, `dblclick`, `fill`, evaluate та інших actions у команду входять target locator, parent frame і options. Browser-side automation layer виконує пошук у правильному контексті та повертає результат або error. На прикладі Chromium автор пояснює роль Chrome DevTools Protocol і показує інструмент командного рядка, який також керує browser через локальний service. Для порівняння Selenium client зазвичай спілкується з browser-specific WebDriver через W3C WebDriver protocol, а driver уже координує browser. В обох випадках test code не клікає DOM напряму: між ним і browser є protocol та процес, що виконує команди.
Playwright дозволяє передати частину параметрів через CLI, але для керованої конфігурації у відео перевизначаються pytest fixtures `browser_type_launch_args` і `browser_context_args`. Перша група відповідає за запуск браузера: `headless`, `slow_mo`, launch timeout і browser channel. Друга — за ізольований browser context: viewport, locale, timezone, permissions, HTTPS errors, headers, base URL та запис відео. Viewport варто обирати з підтримуваних продуктом меж. Мінімальний підтримуваний розмір часто краще виявляє перекриття й недоступні елементи, ніж великий екран розробника. При цьому viewport — це область сторінки всередині браузера, а не повний розмір системного вікна. `slow_mo` корисний для демонстрації або візуальної діагностики, але не є способом синхронізації й не повинен маскувати flaky tests. Надійний тест очікує конкретний стан через locator assertions або іншу умову, а не покладається на постійну затримку між діями.
Playwright підтримує тривалий двосторонній канал із browser process і через browser-specific protocol передає команди click, fill, navigation та читання стану. Locator actions мають auto-waiting: перед дією Playwright перевіряє релевантні actionability conditions — наприклад, видимість, стабільність, можливість отримати events і editable state. Це дозволяє тесту формулювати намір «виконай click для цього locator», а orchestration layer бере на себе очікування готовності елемента в межах timeout. Auto-waiting не усуває потребу в assertion: після дії все одно треба перевірити очікуваний результат. Основні browser engines Playwright — Chromium, Firefox і WebKit. WebKit наближає поведінку Safari, але не є повною копією всіх Safari/macOS/iOS інтеграцій. Branded Chrome або Edge можуть запускатися як Chromium channels, проте повну browser matrix потрібно визначати з реальної product analytics і support policy.
[Дивитися з 04:40](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=280s). Перехід у реалізацію `click()` показує виклик на кшталт `channel.send(...)`: назва команди та її parameters передаються нижчому шару. Далі досліджується ієрархія об’єктів: `Browser` створює `BrowserContext`, context містить `Page`, а page працює з frames і locators. Python- і Java-клієнти не реалізують browser automation незалежно від основного Playwright driver. Вони формують команди та обмінюються повідомленнями з driver process через transport. Саме тому package містить platform-specific executable, а public API різних мов лишається концептуально подібним.
Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.
[Дивитися з 44:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2660s). Підсумкова ієрархія: створюється root `Playwright` instance, далі `Browser`, `BrowserContext` і `Page`; locators працюють у frame/page context. `ChannelOwner` та connection/transport пов’язують language client із driver process, а browser executable і потрібні artifacts перевіряються під час installation та startup. Для співбесіди достатньо пояснити модель без переказу кожного internal class: locator описує target; action збирає parameters; client надсилає command через transport; browser-side implementation виконує потрібні checks та повертає result; Playwright додає auto-waiting, locators, assertions, traces і reporting. Деталі protocol залежать від browser engine і версії Playwright.
Selenium 4 використовує стандартизований W3C WebDriver protocol. Client binding надсилає HTTP-команди WebDriver endpoint, а browser-specific driver виконує їх у Chrome, Firefox, Edge, Safari чи іншому підтримуваному браузері. У старішому Selenium 3 застосовувався JSON Wire Protocol. У класичному Selenium flow перед click або input часто використовується explicit wait: client повторно перевіряє умову на кшталт visibility або clickability, а після її виконання надсилає окрему action command. Це створює більше round trips, особливо коли browser session віддалена. Сильна сторона Selenium — широка екосистема vendor drivers і remote providers. Якщо навіть невелика частка користувачів певного браузера означає сотні тисяч людей або браузер входить у договірну support matrix, таке покриття не можна відкидати лише через повільніший test run. У Python-проєкті технічно можна мати і Playwright, і Selenium tests під pytest: Playwright для основного functional suite, Selenium — для вузької cross-browser перевірки. Це виправдано лише реальною вимогою, бо два automation stacks подвоюють dependency, fixture та maintenance surface.
Стандартні 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.
WebDriver BiDi додає двосторонні події й команди до WebDriver ecosystem: console/network events, більш оперативний browser state та можливості, для яких односпрямованого command-response API недостатньо. У відео технологія описується як така, що ще потребує узгодження версій Selenium, browser і driver та не має однакової зрілості у всіх language bindings. Фінальне порівняння: Playwright — менше ручних waits, багаті debugging artifacts і швидкий workflow для сучасних engines; Selenium — ширша browser/vendor compatibility, але більше інфраструктурних і synchronization витрат. Вибір робиться від support matrix, geography, потрібних protocols і вартості maintenance, а не від загальної популярності інструмента. Практичний default для курсу — Playwright. Selenium варто додавати лише тоді, коли конкретний browser або remote provider є перевіреною вимогою, яку Playwright suite не закриває.