Пошук · Мануфактура

Python мануфактура Java Design Patterns для автоматизаторів

Java · Основний курс · 0:00–8:44

Від простого тесту до підтримуваного коду

Викладач порівнює початковий тест із читабельнішою версією, де послідовність кроків винесена в методи. Такий проміжний варіант полегшує читання, але накопичує всі дії в одному класі, тому його потрібно далі розділити за сторінками. Рефакторинг пояснюється через взаємодоповнювальні принципи. KISS вимагає починати з найпростішого рішення, яке працює; YAGNI — не додавати бібліотеки, підписки, Page Object або AI-інструменти до появи реальної потреби; DRY — помічати дублювання, але не виносити кожен повтор механічно; DAMP — давати змінним, методам і класам описові та змістовні назви. Надмірна архітектура на старті ускладнює супровід та онбординг, а називання сутностей стає легшим лише з практикою.

Page Objects: рефакторинг тестів →

Java · Сесії: AMA та PMP · 12:30–16:30

Standard library, flaky tests і прості принципи дизайну

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.

Що має вміти та знати мідл автоматизатор →

Java · Сесії: AMA та PMP · 25:36–26:20

Як вивчати ООП послідовно

Абстрактні принципи стають зрозумілішими після практики: спочатку помітити code smells, потім розібрати базові механізми ООП, далі — patterns і SOLID. KISS, DRY та YAGNI варто застосовувати паралельно як питання до конкретного коду, а не як привід будувати структуру наперед. Найкраща перевірка розуміння — пояснити, який публічний контракт має клас, який стан йому справді потрібен і яку поточну проблему вирішує кожен виділений метод.

__init__, self, page та принципи ООП →

Java · Сесії: AMA та PMP · 33:00–39:10

Структура automation-проєкту росте ітеративно

Початкова структура може бути простою: спільний config, `web` із pages/components, `api` із clients/controllers та DTO, а за потреби — робота з database. Не треба заздалегідь будувати повну enterprise-ієрархію. Коли database-код розростається, його можна винести на окремий рівень і розділити на entities та repositories/DAO. Це наступна ітерація після появи кількох tables і повторюваних CRUD operations, а не стартова вимога для першого test suite.

Неймінг та структура automation-проєкту →

Java · Основний курс · 1:16:56–1:19:00

Підсумок і практика іменування

Заняття підсумовує перехід від простого KISS-тесту, доповненого YAGNI, DRY і DAMP, до Page Object-структури з очікуваннями та двома способами перевірок: очікувати значення безпосередньо в об'єкті сторінки або повернути дані в тест для окремого порівняння. Для іменування класів, методів, змінних і тестів радять використовувати терміни, уже закладені розробниками: назви з URL, HTML та мережевих запитів, а також фактичні дії користувача. Наступні тести пропонується одразу писати через Page Object і вдосконалювати назви практикою.

Page Objects: рефакторинг тестів →

Java · Advanced: API-автоматизація · 1:30:00–1:50:00

Де закінчується controller

Автор порівнює `Controller`, `Service` і `API` naming. Назва вторинна; головне, щоб class не змішував domains і не ховав assertions. Не кожен endpoint потребує окремого class. Почати варто з одного resource client і розділяти, коли поточний class вже має кілька незалежних responsibilities.

POJO, Jackson і контролери →

Запитати в чаті про «yagni» →