Розширити приклад модуля
Повторити показаний тест.
Додати один новий сценарій.
Зафіксувати failure, причину й мінімальний fix.
Після green run описати один доречний refactoring.
Один додатковий green test і короткий журнал debug/refactoring.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Packages, MVC і resource controllers
Код API automation виноситься в package `api`, а існуючі UI-теси — в `web`. Для подальшої структури автор адаптує ідею MVC: test залишається місцем сценарію та перевірок, DTO описують data model, а controllers містять API operations. Для кожного ресурсу створюється окремий controller, наприклад projects або auth. Дуже великий resource можна розділити на кілька controllers. Під час перейменування Java class в IntelliJ IDEA потрібно використовувати Rename refactoring (`Shift+F6`), щоб назви file і public class залишилися однаковими.
Чому досвід поганого коду теж корисний
Чистий код важко зрозуміти лише з правил. Спочатку інженер пише прямолінійне рішення, потім стикається з duplication, coupling і складним maintenance — і лише тоді бачить, яку конкретну проблему вирішує refactoring або design pattern. Patterns і code smells не застосовуються механічно: різні правила можуть тягнути рішення в протилежні боки. Потрібен контекст, щоб вирішити, коли достатньо простого API call, а коли справді потрібні controller, DTO, serialization та додаткові abstraction layers.
Від простого тесту до підтримуваного коду
Викладач порівнює початковий тест із читабельнішою версією, де послідовність кроків винесена в методи. Такий проміжний варіант полегшує читання, але накопичує всі дії в одному класі, тому його потрібно далі розділити за сторінками. Рефакторинг пояснюється через взаємодоповнювальні принципи. KISS вимагає починати з найпростішого рішення, яке працює; YAGNI — не додавати бібліотеки, підписки, Page Object або AI-інструменти до появи реальної потреби; DRY — помічати дублювання, але не виносити кожен повтор механічно; DAMP — давати змінним, методам і класам описові та змістовні назви. Надмірна архітектура на старті ускладнює супровід та онбординг, а називання сутностей стає легшим лише з практикою.
Повторити, запустити, зламати й виправити
Мінімум для кожного відео — повторити показаний сценарій, запустити тест і самостійно розібратися з проблемами, якщо UI, API або залежності вже змінилися. Після цього варто придумати ще кілька тестів. Курс навмисно веде від сирого синтаксису через повторні рефакторинги до KISS, DRY, SOLID і доречних patterns: цінність дає власний досвід контрольованої помилки, а не готова «ідеальна» архітектура з першого дня.
AI як інструмент оптимізації та межі дозволеного
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
Від простого UI-тесту до Page Objects, API та CI
[Дивитися з 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.
Як здавати практичні роботи
Практику можна здавати після кожного відео або однією завершеною роботою після комплексного рефакторингу модуля. Мінімальна мета — самостійно повторити показаний сценарій; корисніше додати невелике власне розширення, яке підтверджує розуміння. Можна також принести приклад із реального проєкту, навіть іншою мовою програмування. Важливий не формат здачі, а виконана практика та можливість отримати предметний зворотний зв’язок.
Перевіряти mapping на кожному етапі
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.
Extract Method замість дублювання та коментарів
Повторювані кроки авторизації виносяться в `loginUser()`, а коментарі на кшталт «search for project» замінюються методами з відповідними назвами. IntelliJ IDEA може виконати `Extract Method` автоматично та дозволяє перейти від виклику до реалізації через `Command+B` або `Command+Click`. У результаті test method читається як послідовність кроків manual test case: open, login, search, select і wait until loaded.
Масові заміни коду
JetBrains Structural Search and Replace може знайти синтаксичний шаблон і замінити стару конструкцію на нову. ШІ-інструмент теж може допомогти з механічною міграцією, але його результат потрібно перевіряти diff-ом і тестами. Інструмент не визначає коректність автоматично. Спочатку треба зрозуміти новий контракт API, а вже потім масштабувати перевірене перетворення на кодову базу.