Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Спочатку потрібно відкрити `gradle-wrapper.properties` і перевірити потрібну Gradle version. Потім у локальній `.gradle` слід знайти завантажені distributions і видалити пошкоджену або зайву версію, яка не відповідає wrapper configuration, щоб Gradle міг завантажити її заново. Видаляти всі project data для цього не потрібно.
Серед часто вживаних примітивів названо `int`, `boolean`, `double`, `float`, `byte` і `long`. `byte` стане потрібним під час роботи з файлами; для чисел із дробовою частиною або складніших числових операцій автор радить звернути увагу на `BigDecimal`, а не покладатися лише на примітиви. Wrapper classes на кшталт `Integer` надають методи, яких немає у примітивного `int`. Урок не забороняє примітиви: з ними варто поекспериментувати, але коли логіка навколо значення зростає, посилальний тип може бути зручнішим. `while` і `do-while` відкладаються до теми роботи з файлами.
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
Чистий Selenium API придатний до роботи, але тест швидко стає багатослівним. На проєктах це часто приводить до самописних фреймворків, у яких різні Page Objects використовують різні реалізації кліку, пошуку й очікувань. Без одного спільного контракту така обгортка накопичує дублювання та ускладнює супровід. Принципи Selenium однакові для Java, Python, C#, Ruby та інших bindings: клієнт надсилає команди WebDriver, драйвер взаємодіє з браузером. Тому важливіше розуміти модель драйвера, waits, локатори й test runner, ніж запам'ятовувати лише синтаксис однієї мови.
`build.gradle` описує збірку та залежності, Gradle Wrapper дає відтворюваний запуск, а в `src` створюються source sets `main` і `test`. Службова логіка зберігатиметься в `src/main/java`, а тести — в `src/test/java`. Базова ієрархія Java-коду: package містить class, class містить fields і methods, а локальні variables можуть жити всередині methods. Назва `public` class має збігатися з іменем файлу; безпечне перейменування робиться через IDE refactoring.
Після кожної невеликої заміни тест запускається знову. Такий короткий feedback loop показує, на якому саме кроці обгортка змінила поведінку, і не дозволяє накопичити кілька незалежних причин падіння. Для стабільної роботи wrapper має чекати готовності елемента перед дією. Простого eager `findElement` недостатньо: потрібен механізм, у якому пошук або відповідна дія беруть участь у polling loop очікування.
Тест знову падає до виконання text wait, бо `ElementActions` отримує готовий `WebElement`: eager пошук завершується помилкою раніше, ніж запускається очікування. Додавання visibility wait безпосередньо до `find` теж створює суперечність для сценарію, який навмисно очікує invisibility. Рішення — зберігати в `ElementActions` не `WebElement`, а `By`. Реальний пошук виконується лише тоді, коли потрібна дія або конкретна умова. Так один і той самий locator можна використати для visibility, invisibility чи text check, не нав'язуючи стан на етапі створення wrapper object.
Перед `click()` і `sendKeys(...)` wrapper викликає visibility wait для збереженого `By`, а потім виконує дію. Окремо пояснюється різниця між visible і enabled: видимий елемент має координати та розмір, але браузер усе ще може вважати його непридатним до взаємодії. Selenium представляє знайдений вузол через element id, який WebDriver використовує в наступних командах. Якщо DOM замінить вузол між перевіркою стану та дією, посилання може застаріти; саме цей проміжок пояснює частину нестабільних `StaleElementReferenceException`.
Перевірка очікуваного тексту падає через різний регістр. Готовий `textToBePresentInElement` перевіряє входження, але не розв'язує вимогу case-insensitive comparison у потрібній формі. Для `textMatches` створюється `Pattern` із прапорцем `CASE_INSENSITIVE`; очікуваний текст передається до pattern як конкретне значення. Після цієї зміни тест проходить, а фінальний wrapper має окремі реалізації пошуку, actions і waits замість дублювання Selenium-викликів у Page Objects.
Над `Response` будується small fluent wrapper: status, typed body, field/domain assertions, завершення chain. Це дає тесту domain vocabulary і прибирає repeated parsing. Важливо не сховати expected behavior за великим «validateEverything». Fluent method має виражати одну observable property і давати specific failure.