Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Знайдіть поле, де suggestion list з’являється після окремих keyboard events.
Порівняйте fill() і press_sequentially() на тому самому observable result.
Залиште повільніший API лише якщо test доводить потребу в keyboard events.
Два test runs і висновок, який event contract потребує application.
В окремому навчальному repository додайте правила для .venv/, .env і test results.
Перевірте кожен path через git check-ignore -v.
Задайте local user.name і user.email, потім перевірте їх через git config --list --show-origin.
Команди перевірки та staged diff, у якому немає .env і generated artifacts.
Для сторінки зі skeleton, product list і payment iframe вибери мінімальні сигнали, після яких користувач може виконати наступну бізнес-дію.
Кожен signal пов’язаний із реальною наступною дією.
Немає sleeps або перевірки кожного DOM element.
iframe control шукається через frame-aware locator.
Знайдені плитки проєктів зберігаються у змінній типу `ElementsCollection` — власному типі Selenide, пристосованому до роботи з набором UI-елементів. Поруч автор порівнює масиви з `List` і `Set`: колекції мають готові операції для обходу, фільтрації, пошуку, сортування, додавання та очищення. Масив може бути трохи компактнішим або швидшим, але для UI-автотесту ця різниця зазвичай губиться на тлі звернень до браузера. Читання значення з пам’яті триває незрівнянно менше, ніж отримання тексту зі сторінки локально, у Jenkins або через BrowserStack. Тому для звичайних тестів важливіші зручність і читабельність; мікрооптимізації мають сенс лише після вимірювання реальної проблеми, наприклад коли підготовчі дії спотворюють performance test. Для розміру масиву використовується `length`, а для колекції — метод `size()`. IDE підказує доступні операції та може запропонувати stream, але на цьому етапі урок радить залишатися з простішими колекційними API.
Для Jackson2 deserialization явно підключається Jackson Databind. Поля JSON на кшталт `created-at`, які не відповідають Java naming conventions, мають бути явно зв’язані з fields через `@JsonProperty`. Виявляється ще одна контрактна різниця: create endpoint повертає один data object, а list endpoint — array таких objects. Одна й та сама field type не може безпечно представляти обидва shapes, тому моделі розділяються на single response і list response.
[Дивитися з 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.
Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
[Дивитися з 25:45](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1545s). `fill()` фокусує поле, замінює значення та генерує input-related event. Це рекомендований і швидкий варіант для звичайних text fields. Посимвольне `pressSequentially()` потрібне лише тоді, коли application реагує на окремі `keydown`/`keypress`/`input`/`keyup`: autocomplete після перших символів, input mask, formatter номера телефону або custom keyboard handler. Практичний сценарій для autocomplete: ввести мінімальну кількість символів, дочекатися suggestion list, вибрати потрібний option і перевірити кінцевий state. Посимвольне введення не повинно ставати глобальним workaround для слабких очікувань, бо воно робить suite повільнішим.
Lombok `@Accessors(chain = true)` дозволяє ланцюжком викликати setters, а `@Data(staticConstructor = "of")` — створювати object без явного `new`. У демонстрації це скорочує вкладену підготовку request data порівняно з розгорнутим builder. Після створення suite тест має перевірити, що response містить згенерований title. Перший варіант зчитує його з RestAssured response через `jsonPath().getString(...)`; для endpoint, який повертає масив suites, потрібно отримати list titles, а не один string.
Для assertions підключається AssertJ Core, яку автор радить для різних data types і особливо collections. Оскільки suites endpoint повертає масив, тест перевіряє, що list actual titles містить title щойно створеного suite. Перевірка лише title через JsonPath не масштабується на description та інші fields. Тому наступний крок — deserialization повного response в typed Java object і assertions проти його полів.
Новий сценарій шукає project без test cases і перевіряє текст `Zero tests`. Однієї перевірки тексту недостатньо: вона може пройти до завершення фільтрації, тому через Selenide знаходять collection видимих list items і очікують `size(1)`. `$` повертає один елемент, а `$$` — collection, до якої можна застосовувати collection conditions.
Для сталого логування request і response додається custom filter, який реалізує RestAssured `OrderedFilter`. Він логує request до виклику і response після нього, а також не намагається виводити порожнє body. Filter передається в base API configuration, тому всі controllers мають однакову діагностику. Лог показує розбіжності між create і list responses: наприклад, labels в одному response мають інше значення, а description не повертається так, як очікувалося. Частина помилок належить не DTO, а неідеальному API contract.