Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Playwright Test надає isolated page, а locators виражають user-facing contract через label, role і accessible name.
Test проходить лише проти application, що має наведений login contract.
Що має вміти та знати мідл автоматизатор →Повторювані `@BeforeAll` і `@AfterAll` замінюються JUnit 5 extension. `WebDriverLifecycleExtension` реалізує `BeforeAllCallback` та `AfterAllCallback`: до тестів ініціалізує driver через provider, після тестів закриває його. Клас підключається через `@ExtendWith`, тому setup/teardown більше не дублюються в кожному test class. Окремий login extension виконує авторизацію перед тестовим класом. Такі розширення дозволяють комбінувати потрібні preconditions без спільного base class. Наприкінці до wrapper додається `findByText(...)`, який будує XPath і повертає той самий тип actions; тест запускається після виправлення синтаксису локатора.
RestAssured надає BDD-синтаксис `given`/`when`/`then`. У `given` окремо задаються `baseUri`, `basePath`, request parameters і інша підготовка; path радять зберігати без завершального slash, а slash додавати на початку endpoint path. Для login request email і password передаються як `formParam`, після чого виконується `POST`. Спочатку очікується status `200`, а response body має містити token.
Повторюваний login переноситься до `BaseTest`, після чого тест починається з уже відкритої сторінки проєктів. Запуск підтверджує успішну авторизацію, а консольний звіт показує пройдену перевірку `shouldBe(visible)` та її тривалість у мілісекундах. Коли fluent interface утворює довгий вираз, кожну логічну дію варто переносити на окремий рядок. Це не змінює виконання, але дозволяє читати сценарій зверху вниз і швидше співвідносити падіння зі звітом.
[Дивитися з 17:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1050s). Мінімальне завдання першого модуля: автоматизувати login або registration, створення community та перевірку, що після повторної авторизації збереглися введені profile data. YOY дозволяє зареєструватися на event і фактично авторизувати нового user у межах одного flow, тому test має описувати реальну state transition, а не припускати класичний окремий signup screen.
Login-сценарій переноситься до `LoginPage`: тест передає login і password, а Page Object виконує технічні дії з полями та кнопкою. Поширений варіант — передавати `WebDriver` у constructor кожного Page Object, але це повторює однакову залежність у тестах і сторінках. Для навчального врапера обирається централізований provider, з якого Page Objects отримуватимуть поточний драйвер без constructor plumbing. Водночас пакети розділяються за призначенням: web pages залишаються окремо від common-коду обгортки та від можливих API tests.
Типовий login flow проходить через frontend, backend і auth provider: клієнт надсилає ідентифікатор, provider доставляє або перевіряє challenge, backend після підтвердження видає session/token для наступних запитів. Розуміння цього маршруту показує, де саме тест блокується зовнішньою системою. У відео пропонується test-only custom header або спеціальний акаунт, за яким backend пропускає зовнішній challenge. Такий hook допустимий лише з жорстким fail-closed дизайном: production build/config його не реєструє; доступ обмежений тестовою мережею та авторизованим test service; credentials короткоживучі; використання журналюється. Перевірка одного секретного header у production-коді створює критичний auth bypass і є неприйнятною.
Відео досліджує login flow у DevTools: initial cookies, form fields, origin/referer, anti-CSRF values, `302` redirects і callback. Це корисно для debugging та розуміння state machine. Але browser login scraping крихкий: UI form, cookies, CAPTCHA і hidden fields можуть змінитися без API notice. Для production test client треба використати supported OAuth/OIDC library і documented endpoints, а не копіювати browser internals.
Перед автоматизацією 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.
Повторювані кроки авторизації виносяться в `loginUser()`, а коментарі на кшталт «search for project» замінюються методами з відповідними назвами. IntelliJ IDEA може виконати `Extract Method` автоматично та дозволяє перейти від виклику до реалізації через `Command+B` або `Command+Click`. У результаті test method читається як послідовність кроків manual test case: open, login, search, select і wait until loaded.
Projects endpoint повертає колекцію проєктів із title та id. Для прикладу обирається проєкт Manufacture Light, у межах якого потрібно створити test suite. Початковий лінійний сценарій розділяється на methods для login, projects і suites. Кожен method отримує тільки потрібні йому дані: token, project name/id та payload. Це підготовка до винесення API-логіки в controllers.