Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Функція оголошується через `def`, приймає named parameters і може повертати значення. Type hints на кшталт `email: str` та `-> dict[str, str]` покращують navigation і IDE checks, але самі по собі не валідовують input at runtime.
`*locators` збирає довільну кількість positional arguments у tuple, який можна перетворити на list. `**headers` збирає named arguments у dictionary. Ці форми корисні, коли кількість однотипних inputs справді змінна; для стабільного контракту явні parameters читабельніші.
[Дивитися з 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 різних мов лишається концептуально подібним.
OpenAPI JSON/YAML можна передати AI-агенту, але велика специфікація легко перевищує корисний контекст. Не варто просити згенерувати клієнт для всього API, якщо зараз потрібна одна операція. Практичний процес: знайти в документації endpoint, його `operationId` (`getProjects`), спосіб авторизації, parameters і response schema; потім дати агенту лише цей контракт і конкретну задачу.
SAST аналізує codebase, configuration та infrastructure definitions без запуску повного user flow. До scope можуть входити source code, dependencies, YAML, Docker та Terraform files. DAST працює проти запущеного застосунку: генерує requests, змінює parameters, headers, authentication data й шукає небезпечну runtime behavior. OpenAPI specification може бути input для API security scanner-а. Окремі tools аналізують network traffic або вразливості, характерні для конкретної мови, cloud platform, protocol чи IoT stack. Тому pentesting швидко розгалужується на спеціалізації, а не зводиться до ручного перебору requests у Postman.
[Дивитися з 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.
Перед комітом переглядаються видалені plugin parameters, custom fixtures, requirements і параметризовані cases. У підсумку кожна ітерація має читабельний ID, test data винесені з тіла сценарію, а browser reuse виконується через явний fixture graph. Практика після уроку — додати власні cases до таблиці, дати їм змістовні IDs, намалювати залежності fixtures і перевірити setup/teardown кожного scope. Окрема перевірка має довести, що попередня ітерація не залишає авторизацію або client-side state наступній.