Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Current GraphQL-over-HTTP draft requires POST support, permits GET for query operations, forbids GET for mutations and defines non-200 status handling. Тому transport contract треба тестувати за media type і operation, а не очікувати 200 для кожної відповіді.
Точну транспортну специфікацію відео не називає; перевірено проти current draft 2026-07-31.
Вступ до API-автоматизації →Виняткова перевірка всередині Page Object, яка підтверджує, що правильна page та її critical elements готові до operations; business assertions залишаються в test code.
Неймінг та структура automation-проєкту →Design pattern, який відділяє test code від page-specific locators і operations; UI change зазвичай локалізується в одному object.
Неймінг та структура automation-проєкту →Код API automation виноситься в package `api`, а існуючі UI-теси — в `web`. Для подальшої структури автор адаптує ідею MVC: test залишається місцем сценарію та перевірок, DTO описують data model, а controllers містять API operations. Для кожного ресурсу створюється окремий controller, наприклад projects або auth. Дуже великий resource можна розділити на кілька controllers. Під час перейменування Java class в IntelliJ IDEA потрібно використовувати Rename refactoring (`Shift+F6`), щоб назви file і public class залишилися однаковими.
Без API docs можна згенерувати POJO з observed JSON, але це лише semi-automatic recovery. З OpenAPI specification можна відтворювано генерувати models і API client через Gradle/Maven/CLI. Specification містить metadata, servers, paths, operations, schemas і response/error definitions. Swagger UI — лише projection цієї специфікації; code generator працює з machine-readable JSON/YAML.
[Дивитися з 03:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=210s). Багатокрокове створення event містить text fields, images, dates, location/online/hybrid modes, speakers і publish action. Для першої ітерації достатньо послідовних Playwright operations: знайти element, заповнити, натиснути й перевірити видимий результат. Окремі tests можуть покривати різні event types та їх відображення після публікації.
Спільна RestAssured configuration переноситься в abstract `BaseController`. Бібліотека RestAssured має бути доступною main-коду, тому dependency переводиться з test-only у `implementation`. Controllers успадковують base class і працюють з protected request specification. Логін, пошук проєкту і створення suite розносяться між `AuthController`, `ProjectController` і `SuiteController`; controllers та DTO розкладаються в окремі packages. Для порівняння в тому самому class залишається початковий «брудний» сценарій і додається окремий MVC-варіант. Перенесення operations в окремі classes дає змогу розширювати кожен resource без розростання одного test class.
Глибокі XPath не дають переваги в Playwright: потрібні parent/child operations уже є в locator API, а важливішу бізнес-логіку часто краще перевіряти нижче за UI. Команда автоматизації має домовитися з frontend developers про підтримку test attributes і, за можливості, додавати їх через звичайний pull request. Для публічного production DOM слід окремо оцінити, чи не спрощують описові IDs scraping або розкриття внутрішньої структури.
[Дивитися з 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.
Низькорівневі selector, collection і parsing operations виносяться в methods на кшталт `countOfProjectsShouldBeEqualTo`, `countOfTestCasesShouldBeEqualTo` та перевірку total count. Test method після цього показує намір сценарію й очікувані числа, а не деталі DOM. Параметри `expectedSize` або `expectedCount` дають використовувати ті самі перевірки з різними даними.
Shared `RequestSpecification` виноситься в client/configuration method, а resource operations — у methods з domain names, наприклад create/find pet. Тест залишає сценарій і assertions, transport details переходять в client. Рефакторинг починається після working example, а не з speculative framework. Назва class може бути `Client`, `Controller` чи `Service`; важливіше, щоб він відповідав одному resource/service boundary.
Playwright має API для keyboard shortcuts через `page.keyboard().press(...)`, WebSocket events і mocking. Водночас автору бракує ланцюжків на кшталт «динамічно дочекайся тексту, а потім клікни цей самий елемент», тому у власній бібліотеці він додає коротші chainable operations. Окремі actions та assertions приймають options objects. Для конкретної перевірки можна змінити timeout; `FillOptions` і подібні об'єкти дозволяють задати власний timeout або `force`. `force` обходить частину actionability checks і потрібен лише як виняток для проблемного frontend, а не як стандартний спосіб виправляти тести.