Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Raw JSON у Java string швидко стає незручним для large/nested payload і parameterization. JSON file у resources є кращим temporary step, але typed object дає compile-time names/types і IDE support. Розбираються objects, arrays, values, nested arrays і відмінності JSON від XML-style wrappers. Модель має повторювати actual wire shape, а не вигадану class hierarchy.
[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.
Коли `BaseTest` починає відповідати за login, конфігурацію та ініціалізацію всіх Page Objects, він перетворюється на надто широкий контейнер. Ініціалізація сторінок переноситься до окремого `Application`, а тест отримує один об'єкт `app` і звертається через нього до потрібної сторінки. У відео цей підхід порівнюється з агрегатором або facade і застерігається, що глобальний God Object погано масштабується на дуже великі паралельні набори тестів. Для невеликого навчального проєкту Application object спрощує сценарії. Якщо система має окремі домени, наприклад сайт і адмінку, їх можна розділити на `WebsiteApplication` та `AdminApplication` замість одного безмежного контейнера.
Object equality не підходить для всіх API checks. Dates потребують before/after/close-to comparison, floating-point — tolerance, collections — contains/order/filter semantics, nested objects — field-level comparison. AssertJ починає з `assertThat(actual)` і пропонує methods відповідно до actual type. Це зменшує custom comparison code і робить expected behavior видимим у test.
Appium і WebdriverIO дають спільний зовнішній API для iOS та Android, але додають кілька шарів комунікації між тестом, Appium server, platform driver і device. Через це сценарії повільніші, а діагностика instability складніша, ніж у native tests. Одна бізнес-дія також може мати різний UI на різних платформах: date picker, введення числа, back navigation і переходи між екранами підпорядковуються різним design guidelines. Відрізняється й lifecycle: після згортання або повернення екран може відновити state з local storage чи повторно звернутися до backend. Спільний тест часто все одно отримує platform-specific branches або окремі page/screen objects.
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
В IntelliJ IDEA вмикається Full Line completion для Java. На відміну від звичайного completion, яке пропонує проіндексовані класи, методи й доступні члени об'єктів, Full Line completion намагається запропонувати цілий рядок на основі контексту коду. Викладач описує цю модель як локальну й радить спочатку попрацювати саме з нею. GitHub Copilot може запропонувати кілька рядків, метод або клас, але така генерація не гарантує коректності. Для повторюваних Page Objects і тестових дій підказки можуть бути доречними, проте кожну пропозицію потрібно читати й перевіряти. У відео також наголошено на відмінності між локальною моделлю та передаванням контексту сторонньому сервісу.
[Дивитися з 04:40](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=280s). Перехід у реалізацію `click()` показує виклик на кшталт `channel.send(...)`: назва команди та її parameters передаються нижчому шару. Далі досліджується ієрархія об’єктів: `Browser` створює `BrowserContext`, context містить `Page`, а page працює з frames і locators. Python- і Java-клієнти не реалізують browser automation незалежно від основного Playwright driver. Вони формують команди та обмінюються повідомленнями з driver process через transport. Саме тому package містить platform-specific executable, а public API різних мов лишається концептуально подібним.
Щоб будувати виклики через крапку, метод Page Object замість `void` повертає поточний тип і завершується `return this`. Так `open()` може повернути `SignInPage`, після чого одразу викликається `loginUser(...)`. У відео цей стиль пов'язують із назвами fluent interface та chain of invocation; у заголовку уроку також використано Chain of responsibility. Повернення `this` зручне для послідовності дій у межах одного Page Object. Повертати з кожного методу наступну сторінку викладач не радить: довгі ланцюжки приховують переходи й ускладнюють code review. Допустимий локальний виняток — компонент або popup, який належить поточній сторінці й природно стає наступним об'єктом взаємодії. Спільні значення, потрібні кільком тестам, переносяться до наявного `BaseTest`, а не дублюються. Для них обирається найвужча достатня видимість, у прикладі — `protected` для класів-нащадків.
Первинні перевірки мають бути видимими в тесті, а не захованими в controller. Тому API method повертає `Response`, а test явно перевіряє status code. Така структура спрощує code review і показує, що саме доводить сценарій. Наступний крок — замінити JSON strings на data transfer objects, щоб мати Java types, autocomplete і зручне оновлення полів. Додаються Java Faker для унікальних test data і Lombok для генерації boilerplate. Для Lombok у IntelliJ IDEA потрібні plugin і ввімкнений annotation processing.