Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
У повсякденній мові __init__ часто називають constructor, але Python data model розділяє __new__, який створює instance, і __init__, який налаштовує вже створений instance.
__init__, self, page та принципи ООП →Загальноприйнята назва першого параметра instance method. Python передає bound instance неявно під час виклику obj.method(), але ім’я self саме по собі не є keyword.
__init__, self, page та принципи ООП →page є instance attribute: кожен PageObject отримує власний стан через __init__, а method читає його через self.
Команда друкує Page: checkout і assertion проходить.
__init__, self, page та принципи ООП →Створи два PageObject instances із різними page values і доведи assertions, що зміна local variable не змінює self.page іншого instance.
Обидва instances мають незалежні page attributes.
У method немає global state.
Автор може пояснити, чому obj.method() передає obj як перший argument.
Описує binding instance methods, self convention і межі private variables у Python.
__init__, self, page та принципи ООП → Першоджерело ↗Уточнює різницю між створенням instance через __new__ та ініціалізацією через __init__.
__init__, self, page та принципи ООП → Першоджерело ↗`self` — явний параметр instance method, через який код звертається до конкретного екземпляра класу. `self.card` означає атрибут цього екземпляра, тоді як локальна змінна `card` живе лише у своїй функції або блоці видимості. Однакові назви технічно можливі, але збільшують когнітивне навантаження. Префікс `self.` одночасно потрібен Python для правильного доступу до instance attribute і показує читачеві, де зберігається стан.
Стандартні 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.
[Дивитися з 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.
Class name зазвичай є іменником в однині та пишеться з великої літери. `__init__` приймає початковий state, а `self.email` і `self.role` належать конкретному object instance. Method `is_admin()` розміщує перевірку ролі біля даних і не змушує кожен test повторювати `user.role == "admin"`.
Перший виклик виправляється після звірки з API: треба створити екземпляр `Faker()`, а вже потім викликати його provider, наприклад `fake.password(length=10)`. Повторні запуски демонструють різні значення. Змінна називається `invalid_password`, щоб тест явно пояснював роль даних. Практична межа рандомізації: при падінні варто логувати або зберігати згенероване значення чи seed, інакше дефект може бути важко відтворити.
Клієнт містить лише потрібні операції: authentication і `get_projects`. У прикладі використано `httpx`, хоча для синхронного сценарію стандартний для проєкту HTTP-клієнт також достатній; не слід додавати dependency лише через згенерований AI-код. Авторизований client надається через pytest fixture. JWT кешується всередині instance, щоб кілька endpoint calls одного тестового lifecycle не повторювали login. Спочатку окремі API-тести перевіряють успішну авторизацію та непорожній список проєктів.
Після рефакторингу suite падає через змішування plugin-managed fixtures та вручну створеного sync Playwright instance. Додатково частина launch/context options дублюється в dictionary і кількох fixtures, що робить конфігурацію непослідовною. Рішення у відео — перейти на один спосіб володіння lifecycle: custom fixtures запускають Playwright і browser, а конфігурація збирається в одному місці. Частину pytest-playwright параметрів прибирають, бо custom launcher їх уже не читає. Загальний висновок: не можна одночасно очікувати, що plugin і власний код керуватимуть тим самим browser lifecycle.
API package містить client і мінімальні response models, fixture повертає авторизований client, а UI-тест використовує тільки потрібний endpoint для setup. Login token не перевипускається перед кожною операцією instance. Практична вправа — реалізувати аналогічний precondition через наявний у проєкті HTTP client (`requests`, `httpx` або Playwright APIRequest), перевірити authentication окремо й лише потім під’єднати результат до UI-сценарію.