Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
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.
Для assertions підключається AssertJ Core, яку автор радить для різних data types і особливо collections. Оскільки suites endpoint повертає масив, тест перевіряє, що list actual titles містить title щойно створеного suite. Перевірка лише title через JsonPath не масштабується на description та інші fields. Тому наступний крок — deserialization повного response в typed Java object і assertions проти його полів.
Release notes бібліотек варто читати не лише заради нових API: пояснення змін часто показує обмеження старої поведінки, причини перенесення функціоналу та deprecated можливості. Для clipboard і `localStorage` достатньо самостійно відкрити документацію та зробити короткі експерименти на навчальному сайті. Головне завдання — попрактикуватися з колекціями елементів і порівняти підходи на власному прикладі. Окрема домашня робота — прочитати про ієрархію Java Collections Framework; у повсякденних тестах найчастіше знадобляться `ArrayList` і `Map`.
Знайдені плитки проєктів зберігаються у змінній типу `ElementsCollection` — власному типі Selenide, пристосованому до роботи з набором UI-елементів. Поруч автор порівнює масиви з `List` і `Set`: колекції мають готові операції для обходу, фільтрації, пошуку, сортування, додавання та очищення. Масив може бути трохи компактнішим або швидшим, але для UI-автотесту ця різниця зазвичай губиться на тлі звернень до браузера. Читання значення з пам’яті триває незрівнянно менше, ніж отримання тексту зі сторінки локально, у Jenkins або через BrowserStack. Тому для звичайних тестів важливіші зручність і читабельність; мікрооптимізації мають сенс лише після вимірювання реальної проблеми, наприклад коли підготовчі дії спотворюють performance test. Для розміру масиву використовується `length`, а для колекції — метод `size()`. IDE підказує доступні операції та може запропонувати stream, але на цьому етапі урок радить залишатися з простішими колекційними API.
Для middle і особливо senior рівня очікується розуміння типів даних, проходу collections, роботи з files та databases, object lifecycle, scope variables, initialization order і test runner lifecycle. Ці знання зазвичай закріплюються після реальної проблеми, а не після ізольованої лекції. Тому відповідь не вимірюється списком syntax topics. Junior має безпечно змінювати прості scripts; middle — діагностувати non-obvious behavior; senior — пояснювати system-level root cause й обирати правильний test seam.
Middle має орієнтуватися у standard library та основних конструкціях мови: collections, functions, reserved words/operators, способи створення й перетворення даних. Це дає змогу використовувати вбудовані можливості замість зайвих dependencies і custom wrappers. Окремий практичний блок — діагностика flaky tests: відрізнити проблему очікування, нестабільні дані, shared state, зовнішню залежність або справжню race condition. `retry` не є виправленням першопричини. Для дизайну automation code достатньо впевнено застосовувати KISS, DRY, YAGNI та DAMP. SOLID і design patterns корисні як словник для конкретних проблем, але не як вимога створювати багатошарову архітектуру. Також потрібно вміти запускати suite у CI та читати test report.
Після першої мови наступна засвоюється швидше, бо основні задачі повторюються: прочитати або записати file, пройти collection, зберегти structured data, виконати network request, звернутися до database й запустити test runner. Змінюються syntax, libraries та окремі runtime semantics. Практичний орієнтир: добре вивчити одну мову на реальних задачах, а другу брати тоді, коли вона відкриває дешевший або надійніший спосіб вирішити поточну проблему. AI допомагає швидше знайти syntax, але не замінює перевірку architecture і behavior.
Новий сценарій шукає project без test cases і перевіряє текст `Zero tests`. Однієї перевірки тексту недостатньо: вона може пройти до завершення фільтрації, тому через Selenide знаходять collection видимих list items і очікують `size(1)`. `$` повертає один елемент, а `$$` — collection, до якої можна застосовувати collection conditions.