Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
У відео сценарій побудований навколо cookies, storage state та companyId для вибору ролі.
Актуальний API також уміє включати IndexedDB через indexed_db (додано у v1.51) і virtual WebAuthn credentials через credentials (додано у v1.61).
На сторінці може бути різний контент — що робити? →Збережені cookies і headers для повторного використання авторизованої browser session. Такий файл може дозволити impersonation test account, тому його не слід комітити навіть у private repository; shared account підходить лише для tests без конфліктних server-side mutations.
Практика курсу на YOY, домашні завдання та формат ПМП →State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.
На сторінці може бути різний контент — що робити? →Ізольоване browser profile у Playwright. Playwright Test створює окремий context для кожного test, ізолюючи cookies, local storage і session storage.
Що має вміти та знати мідл автоматизатор →Ізольоване браузерне середовище Playwright. Окремі contexts не ділять cookies та інший стан, що підтримує відтворюваність тестів.
На сторінці може бути різний контент — що робити? →Знімок стану BrowserContext, який охоплює cookies, localStorage та, за явними options актуального API, IndexedDB або virtual WebAuthn credentials.
На сторінці може бути різний контент — що робити? →Відео досліджує 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.
Щоб зрозуміти, чому UI різниться, потрібно дивитися не лише на сторінку. У DevTools варто перевірити `Network`, cookies, `localStorage` і `sessionStorage` та знайти дані, які визначають активну компанію або роль. У прикладі різницю задає `companyId`: конкретний ID відкриває корпоративний контекст, а відсутнє значення — free-проєкти. Це дає точну підказку, який стан треба підготувати перед тестом.
Демо послідовно відтворює open login page, authenticate user, follow location/callback, extract authorization code і exchange it for tokens. Cookies оновлюються між кроками, тому shared state має бути explicit. Велика частина демо — live debugging невірного client/redirect та reverse engineering кроків. Практичний висновок: автоматизувати лише documented grant, а browser trace використовувати для пошуку discrepancy.
Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.
Умови WebDriver дозволяють перевіряти URL, title, cookies та інший стан браузера. Автор застерігає від беззмістовної перевірки випадкового фрагмента URL: вона подібна до перевірки елемента лише за індексом і не доводить, що користувач отримав потрібний результат. URL-condition виправданий для redirects або query parameters із предметним значенням — наприклад, коли треба підтвердити джерело переходу з Google, Hotline, соціальної мережі чи іншого метапошуку. В інших випадках краще чекати спостережуваний стан сторінки через предметний `isLoaded`-метод.