Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Візьміть один feature flow і перевірте його через frontend, API та persistence boundaries. Зафіксуйте contract для time fields, кількість backend/provider calls, authorization states і system-level regression risks.
Короткий risk-based review із конкретними evidence та переліком перевірок, яких бракує.
Перед автоматизацією API потрібно дослідити, як із ним працює frontend. Network tab дає фактичні requests навіть тоді, коли документації немає або вона застаріла. На прикладі sign-in показано `POST` зі status `302`, що може свідчити про Backend for Frontend або gateway із власною логікою. Форма відправляє email, password, ознаку remember me і authenticity token. Якщо API не має окремого login endpoint, автотест може завантажити HTML, витягнути токен і відтворити `application/x-www-form-urlencoded` request. У відео натомість використовується задокументований API token/login flow. Автор окремо показує, що payload може бути form data або JSON.
Глибокі XPath не дають переваги в Playwright: потрібні parent/child operations уже є в locator API, а важливішу бізнес-логіку часто краще перевіряти нижче за UI. Команда автоматизації має домовитися з frontend developers про підтримку test attributes і, за можливості, додавати їх через звичайний pull request. Для публічного production DOM слід окремо оцінити, чи не спрощують описові IDs scraping або розкриття внутрішньої структури.
Окрім REST, системи використовують WebSocket, gRPC і GraphQL. Протокол обирається під задачу, тому перед автоматизацією потрібно зрозуміти не лише endpoint, а й модель комунікації. Backend for Frontend — це gateway з контрактом, зручним для конкретного client: web frontend, mobile application або окремого screen. Зовні він відкриває потрібні resources, а всередині може агрегувати кілька services з їхніми базами і queues.
ORM є компромісом: прискорює типову розробку, але може генерувати неефективні queries або приховувати N+1, зайві joins і transaction behavior. Повертатися до ручного SQL слід за профілем і вимірюванням, а не через загальну недовіру до abstraction. У бажаній архітектурі backend виконує бізнес-перетворення, а frontend переважно відображає готовий contract. Якщо значна logic усе ж живе на frontend, це підсилює цінність UI/component automation. Коли продукт створюється з нуля й UI ще немає, логічно почати з API. Для наявного продукту без automation перший seam вибирають за ризиком і вартістю ручної регресії, а не за універсальним правилом «завжди UI» або «завжди backend».
Frontend збирає поведінкові signals і отримує token; backend передає token провайдеру та порівнює отриманий score з власним threshold. Автотест виглядає як бот і часто отримує низький score. Для test environment використовують офіційний test key або узгоджений mode, у якому frontend не показує challenge, а backend не викликає production verification. Так тест перевіряє application flow, не підмінюючи окрему перевірку реальної CAPTCHA integration.
Після узгодження behavior загальний scenario треба декомпозувати. Frontend task описує component, validation і UI states; backend task — endpoint, contract і business rule; test task — ризики й потрібне coverage. Для інженера прямий технічний опис часто коротший і точніший за повторення кожної умови через `Given/When/Then`. Проблема починається, коли один формат примусово використовують для всіх ролей. Business не має керувати деталями automation code, а automation engineer не повинен перекладати вже зрозумілий technical contract у довший Gherkin лише для формальної відповідності процесу.
[Дивитися з 08:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=480s). Досвідчений engineer із точним plan може реалізувати frontend, backend і частину deployment pipeline, використовуючи готову design system та API contract. Frontend має знати, який resource і endpoint запросити; backend — який response повернути; shared components і design tokens дають повторюваний UI. AI допомагає заповнити реалізацію, але не визначає самостійно правильні boundaries і product behavior.
Дані, які бачить користувач, приходять з backend services, тому UI scenario часто можна розкласти на більш швидкі API checks. Спочатку треба з’ясувати API maturity: чи є specification, чи вона актуальна, як frontend реально викликає endpoints. Якщо documentation немає або їй не можна довіряти, browser DevTools/Network дає фактичні URL, method, headers, payload і response. Це джерело для discovery, але не заміна погодженого contract.
`#search` знаходить елемент з `id="search"`. Довільний attribute записується у квадратних дужках: `[name='viewport']`. Коли значення має стабільну частину та змінний hash, оператор `*=` дає пошук за підрядком. Це корисно для generated attributes у frontend frameworks, але стабільна частина має бути досить специфічною, щоб не отримати кілька збігів.
Один і той самий service може бути producer для одного виклику і consumer для іншого. Тому response, яку отримує frontend, може залежати від кількох внутрішніх викликів. Чиста теоретична модель не завжди збігається з production: дедлайни змушують команду накопичувати technical debt і порушувати ідеальні межі. Тестувальник має досліджувати фактичні зв’язки, а не покладатися лише на назви сервісів.