Відеобібліотека
Пошук у нотатках курсу 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, прараметризація тестів →Межа кешування й teardown fixture: function, class, module, package або session. Залежність може використовувати fixture того самого або ширшого scope, але не вужчого.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Pytest fixture зі scope session створюється один раз на test session, тому підходить для незмінної конфігурації всього запуску.
Рівень, з якого Git читає setting: system, global, local, worktree або command. --show-origin і --show-scope допомагають знайти джерело ефективного значення.
Коли робота відрізняється від очікувань, Developers і Product Owner переглядають scope Sprint Backlog, не руйнуючи Sprint Goal.
Як працювати на спокійному проєкті та з нав’язаними оцінками →HTML Standard вимагає, щоб id був унікальним у межах element tree. Scope до desktop container може стабілізувати test, але root fix належить frontend markup.
Pytest fixture може мати scope `session`, `package`, `module`, `class` або `function`. Чим ширший scope, тим рідше створюється ресурс: session fixture — один раз на весь test run, function fixture — окремо для кожного тесту. Код до `yield` виконує setup, а після `yield` — teardown відповідного scope. Ціль уроку — перетворити один негативний login test на параметризований. Тіло сценарію залишається одним, а різні пари email/password та читабельні case IDs передаються як дані.
[Дивитися з 14:25](https://www.youtube.com/watch?v=reaHS8_pZbU&t=865s). Якщо estimate нав’язано ззовні, команда не повинна регулярно рятувати його unpaid overtime: тоді management бачить лише формально виконаний plan і не отримує evidence, що estimation process зламаний. Потрібно фіксувати фактичний effort, невідомі залежності, скорочений testing scope та carry-over, а на retrospective вимагати участі виконавців в оцінюванні. Сильніша позиція виникає, коли кілька інженерів незалежно описують ту саму проблему фактами. Спочатку питання піднімають із tech lead/engineering lead, потім — на retro або з manager, якщо прямий канал не працює. Повідомлення має бути не «ми не хочемо встигати», а «за такого scope й available capacity безпечний результат потребує X; до deadline можемо завершити Y, решту переносимо або свідомо приймаємо перелічені ризики». У відео також звучить ідея зробити недооцінку видимою через накопичення нестабільних tests і technical debt. Навмисно ламати quality gate не варто: це створює product risk і послаблює аргументацію команди. Правильний еквівалент — не приховувати незавершену роботу, явно документувати deferred checks/debt, не позначати неперевірене як done і вимагати product decision про scope, deadline або quality.
[Дивитися з 00:00](https://www.youtube.com/watch?v=reaHS8_pZbU&t=0s). У великій компанії частіше вже сформовані processes, розподіл відповідальності й розуміння, що постійний overtime шкодить людям і результату. Але розмір сам по собі нічого не гарантує: work-life balance треба перевіряти конкретними питаннями на співбесіді. Корисно запитати, хто оцінює work, чи бере участь команда, як змінюється scope після estimate, що відбувається при невиконанні sprint commitment і чи оплачуються понаднормові години. Регулярний overtime зазвичай вказує на проблему з prioritization, scope changes або estimation, а не на недостатню відданість інженера. Власні estimates радять робити з резервом на невідомі залежності, перевірку та recovery після помилок.
Функцію можна оголосити всередині іншої, тоді вона доступна лише в зовнішньому function body. Це інколи допомагає розкласти великий transform, але single-use nested helper не завжди покращує код. Якщо логіка потрібна в кількох місцях, її краще зробити звичайною module-level function із чітким контрактом.
У двох тестах повторюється авторизація, тому з’являється fixture `login_user`. Fixture розглядається як механізм підготовки та, за потреби, очищення стану до/після тесту. Для логіну обирається scope `function`: підготовка виконується окремо перед кожним тестом, який явно запитує fixture. Це ізолює сценарії й не поширює авторизований стан на тести, яким він не потрібен.
Стандартні 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.
`self` — явний параметр instance method, через який код звертається до конкретного екземпляра класу. `self.card` означає атрибут цього екземпляра, тоді як локальна змінна `card` живе лише у своїй функції або блоці видимості. Однакові назви технічно можливі, але збільшують когнітивне навантаження. Префікс `self.` одночасно потрібен Python для правильного доступу до instance attribute і показує читачеві, де зберігається стан.
Компанія — не сім’я, але здоровий менеджмент має пам’ятати, що працює з людьми. Не варто компенсувати проблеми проєкту постійним overtime. Якщо є виснаження, перший крок — зменшити scope, використати відпустку, повернути хобі й час із близькими. Sabbatical доречний, коли є фінансова подушка та реальна можливість його взяти. Матеріальний стан важливий, але його треба співвідносити з ціною для психологічного здоров’я; рішення не варто зводити лише до максимальної зарплати.
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
Пропонується думати не про формальний work-life balance, а про загальний life balance — власний порядок пріоритетів. Комусь підходить відповідальність за бізнес або команду, а комусь — стабільний інженерний scope, передбачуваний відпочинок і менше токсичності. Перехід із менеджменту в технічну роль або навпаки — звичайний етап життя. Його можна прямо пояснити recruiter або майбутній команді: людина спробувала інший тип роботи й зрозуміла, де має більше інтересу та задоволення.