Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Спочатку потрібно відкрити `gradle-wrapper.properties` і перевірити потрібну Gradle version. Потім у локальній `.gradle` слід знайти завантажені distributions і видалити пошкоджену або зайву версію, яка не відповідає wrapper configuration, щоб Gradle міг завантажити її заново. Видаляти всі project data для цього не потрібно.
Якщо проблема лишилася, можна послідовно спробувати `Repair IDE`, `Invalidate Caches` і `Reopen Project`, після чого знову запустити test. Додаткова ознака проблеми з Gradle indexing — відсутні `Tasks` і `Dependencies` у Gradle tool window. У справно проіндексованому project там видно task groups, зокрема `verification`, і test task, який IDE запускає під капотом.
Початковий симптом — помилка на кшталт `zip ... not found` під час запуску tests. Імовірна причина в показаному випадку: Gradle distribution не завантажився або не розпакувався повністю через брак disk space чи memory. Кнопка Run в IDE зрештою виконує command-line Gradle task, тому збій нижчого tool layer не виправляється повторним натисканням Run.
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
У Aqua створюється Selenium-проєкт з Java, Gradle і JUnit 5. `group` використовується як простір імен, а `artifact` — як назва конкретного проєкту. Для курсу обрано JDK 17; автор демонструє Amazon Corretto, але радить узгоджувати дистрибутив з проєктною командою. До залежностей додаються Selenium і Selenide; після створення проєкту треба дочекатися завершення Gradle sync.
`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.
Створюється Java/Gradle project з group/package naming, JUnit Platform і dependencies. Відео використовує Java 11/17 і пояснює різницю Maven та Gradle як build tools. Repositories та artifact storage потрібні не лише для third-party libraries: компанія може публікувати власні clients і test artifacts. Точні dependency versions мають бути pinned і відтворювані на CI.
Перед commit потрібно переглянути кожен changed line і переконатися, що `.env` не потрапив до repository. Gradle configuration коригується так, щоб tests можна було запускати з command line через `gradle test`, а не лише кнопкою IDE. `@BeforeAll` виконує спільний open/login один раз перед усіма tests, `@BeforeEach` може перевідкривати home page перед кожним test; наприкінці автор пропонує так само дослідити відповідні after hooks.
Курс орієнтований на кодову автоматизацію, а не на record/playback чи no-code рішення. Як цільову систему використано Testomat.io: курс охоплюватиме UI та окремі API-операції. Автор рекомендує встановити JetBrains Aqua, а Java/JDK завантажити безпосередньо через IDE. Gradle або Maven знадобляться для керування збіркою, залежностями та консольного запуску тестів.
Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.