Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
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-тест — доступність повного сценарію. Розгалуження між цими очікуваннями в одному тесті приховує дефект, якщо середовище випадково відкрило не ту роль.
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 і сканування вразливостей. Якщо зовнішній пакет не дозволений, команда або погоджує його через встановлений процес, або реалізує мінімально потрібну поведінку самостійно — хоча власний код теж має вартість підтримки й не є автоматично безпечнішим.
[Дивитися з 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 та подальша підтримка все ще потребують людей і бюджету.
Початкова структура може бути простою: спільний config, `web` із pages/components, `api` із clients/controllers та DTO, а за потреби — робота з database. Не треба заздалегідь будувати повну enterprise-ієрархію. Коли database-код розростається, його можна винести на окремий рівень і розділити на entities та repositories/DAO. Це наступна ітерація після появи кількох tables і повторюваних CRUD operations, а не стартова вимога для першого test suite.