Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Зіставте class name з route, visible heading і product vocabulary.
Позначте methods, які маскують click як open, або змішують action і assertion.
Перейменуйте лише підтверджені невідповідності та запишіть два project rules у README.
Один короткий diff і два naming rules, які прибирають повторну суперечку на code review.
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
Клієнт звертається до одного зовнішнього API gateway, хоча за ним працюють окремі user/account та appointment services. Gateway перетворює зовнішній route і проксіює request у внутрішню мережу до відповідного service; зовнішнє й внутрішнє найменування ресурсу може відрізнятися. Service, у свою чергу, може читати кілька tables, звертатися до інших services, виконувати filters і mappings, а controller повертає сформовану DTO. Тому response одного endpoint залежить не від одного методу, а від усього ланцюжка.
Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне `401`, бо потрібний header загубився між ними. API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.
Playwright може чекати завершення request або появи response під час конкретної дії. У власній обгортці автора це оформлено як `clickWithWaitForRequestFinished`: всередині викликається Playwright network wait, а дія click передається callback-ом. У документації також показані перехоплення request/response, `route` і `fulfill`, тобто можливість змінити або підмінити API response. У відео ці приклади не реалізуються повністю: головна мета — показати доступний механізм і запропонувати дослідити його в домашній роботі. Network wait корисний не лише для синхронізації UI, а й для перевірки analytics чи інших events, що мають бути відправлені після кліку. Автор радить зберігати однаковий читабельний порядок у тестах — дія, а потім очікуваний результат — навіть якщо базовий API описує wait до callback-дії.