Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Fixture створює isolated BrowserContext із наперед підготовленим Free-state; Enterprise-state має бути окремою fixture або parameterized input із чіткою очікуваною роллю.
Тест стартує у визначеному Free-контексті без умовного розгалуження за випадковим UI-станом.
На сторінці може бути різний контент — що робити? →Візьми тест, який допускає Free або Enterprise через if, і розділи його на дві fixtures та два тести з однозначними assertions.
Кожен тест має одну відому роль до першої UI-дії.
У test body немає гілки, що вибирає очікування за фактичним тарифом.
State-файли не містяться в Git.
Free plan, trial та enterprise мають різні можливості: ліміти створення проєктів, доступні кнопки й повідомлення. Це окремі вимоги рольової моделі, тому їх варто перевіряти окремими тестами. Наприклад, free-plan тест підтверджує відповідну позначку тарифу та обмеження створення проєкту, а enterprise-тест — доступність повного сценарію. Розгалуження між цими очікуваннями в одному тесті приховує дефект, якщо середовище випадково відкрило не ту роль.
Якщо функціональність залежить від ролі, тарифу або tenant, тести доцільно групувати за відповідним станом користувача. У прикладі один акаунт має доступ до Enterprise і Free проєктів, але в реальній системі це можуть бути окремі користувачі. Перед реалізацією досліджується UI, Network, cookies та local storage. Перемикання проєкту змінює `Company ID`; додатковими спостережуваними ознаками є тексти `Enterprise subscription` і `Free subscription`.
Tooltip із назвою тарифу з’являється після hover, тому тест спочатку знаходить стабільний label, виконує hover і лише потім перевіряє текст підписки. DOM/attribute breakpoints допомагають зрозуміти, який компонент створює анімацію. Повторювані елементи Enterprise і Free додаються в page object, а тест перевіряє стан до та після `select_company`. Це формує observable contract, на який можна спертися під час оптимізації авторизації.
Загальні сценарії, наприклад login, залишаються спільними. Перевірки, залежні від тарифу, розкладаються в окремі packages для Free та Enterprise, кожен зі своєю fixture. Підсумкова схема: на першому чистому запуску state створюється; надалі він перевикористовується; page не перестворюється; кожен тест може запускатися окремо. Зміни комітяться з номером задачі та коротким описом storage, page initialization і структури suites.
Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
На enterprise-проєктах доступ до публічних package registries часто обмежують. Дозволені бібліотеки та внутрішні збірки зберігають у корпоративному artifact repository або пропускають через контрольований proxy. Такі сховища дають версіонування, allowlist і сканування вразливостей. Якщо зовнішній пакет не дозволений, команда або погоджує його через встановлений процес, або реалізує мінімально потрібну поведінку самостійно — хоча власний код теж має вартість підтримки й не є автоматично безпечнішим.
Перший варіант дублює Enterprise state й через стандартний модуль `json` очищає cookie `Company ID`. Пошук проходить масив cookies, змінює лише елемент із потрібним `name` і записує окремий файл. Цей підхід є оптимізацією для конкретного застосунку, а не універсальним правилом Playwright. Якщо backend session або інший state також прив’язаний до tenant, безпечніше реально перемкнути проєкт у браузері й зберегти отриманий context.
[Дивитися з 21:47](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1307s). Одна-дві людини з агентами можуть швидко створити alpha або beta й навіть працювати з великою enterprise codebase, якщо моделі мають достатній контекст. Але продуктивність має спиратися на quality gates: CI/CD, tests, performance checks, review іншими агентами та явні артефакти. Якщо команда не читає код і результати test runs, за пів року чи рік накопичуються зміни, які важко підтримувати, масштабувати й діагностувати. Тоді знову потрібні інженери з глибокими знаннями architecture, backend, PostgreSQL, messaging та конкретного domain.
[Дивитися з 31:22](https://www.youtube.com/watch?v=crzGm6nzfbU&t=1882s). Малий бізнес зможе дозволити собі одного-двох інженерів для власної CRM, аналітики чи інтеграцій, але слабка інженерна база збільшить кількість data-loss, authentication і maintenance incidents. Enterprise adoption стримують privacy та заборона передавати proprietary code стороннім моделям. Паралельно AI і генерує security vulnerabilities, і допомагає знаходити давні дефекти. Єдиної відповіді для ринку немає: AI дає величезну можливість швидко реалізувати ідею, але deployment, domain, observability, security та подальша підтримка все ще потребують людей і бюджету.