Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Java з переходом на потрібну секунду.

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

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

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 залишилися однаковими.

API-автоматизація: MVC і Jackson →

Java · Основний курс · 5:20–11:53

`BaseController` і порівняння лінійного та controller-based тесту

Спільна RestAssured configuration переноситься в abstract `BaseController`. Бібліотека RestAssured має бути доступною main-коду, тому dependency переводиться з test-only у `implementation`. Controllers успадковують base class і працюють з protected request specification. Логін, пошук проєкту і створення suite розносяться між `AuthController`, `ProjectController` і `SuiteController`; controllers та DTO розкладаються в окремі packages. Для порівняння в тому самому class залишається початковий «брудний» сценарій і додається окремий MVC-варіант. Перенесення operations в окремі classes дає змогу розширювати кожен resource без розростання одного test class.

API-автоматизація: MVC і Jackson →

Java · Основний курс · 1:20:17–1:23:19

Повторне використання token і controllers у `BaseTest`

Щоб не передавати token в кожен controller method, `BaseController` зберігає його у field і додає authorization header, якщо значення не порожнє. Token-setting method повертає controller type, щоб його можна було викликати у fluent chain. Після цього resource methods більше не мають token parameter. Controller instances та login setup виносяться в `BaseTest`. Token отримується один раз у `@BeforeAll`, після чого ним конфігуруються `ProjectController` і `SuiteController`. Фінальний test залишає видимими лише сценарій, test data і assertions, а transport details залишаються у controllers.

API-автоматизація: MVC і Jackson →

Java · Основний курс · 20:38–24:30

Пошук проєкту і виділення API methods

Projects endpoint повертає колекцію проєктів із title та id. Для прикладу обирається проєкт Manufacture Light, у межах якого потрібно створити test suite. Початковий лінійний сценарій розділяється на methods для login, projects і suites. Кожен method отримує тільки потрібні йому дані: token, project name/id та payload. Це підготовка до винесення API-логіки в controllers.

Rest Assured: базове використання →

Java · Сесії: AMA та PMP · 22:13–24:35

Дані, GDPR і прямий REST-доступ до PostgreSQL

[Дивитися з 22:13](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1333s). Backend testing охоплює не тільки response body, а й правила зберігання, видалення та повідомлення користувача про персональні дані. Навіть архітектура без окремих controllers — наприклад, REST-інтерфейс поверх PostgreSQL через PostgREST — не скасовує перевірок access control, фільтрації та дозволених операцій. Прямі CRUD-запити можуть бути простими синтаксично, але безпека й видимість rows усе одно залежать від правил у шарі даних.

Прихована складність бекенд-тестування →

Java · Основний курс · 1:02:20–1:09:00

Custom RestAssured log filter і розбіжності даних

Для сталого логування request і response додається custom filter, який реалізує RestAssured `OrderedFilter`. Він логує request до виклику і response після нього, а також не намагається виводити порожнє body. Filter передається в base API configuration, тому всі controllers мають однакову діагностику. Лог показує розбіжності між create і list responses: наприклад, labels в одному response мають інше значення, а description не повертається так, як очікувалося. Частина помилок належить не DTO, а неідеальному API contract.

API-автоматизація: MVC і Jackson →

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

Resource controllers і negative responses

Коли один endpoint method потрібен кільком тесам, він переходить у resource controller/service. Межа class залежить від real API: окремий service на resource або кілька related resources в одном service client. Для negative tests controller краще повертати raw `Response`, щоб test явно перевірив status, headers і error body. Примусова deserialization success DTO для `4xx/5xx` сховає реальний contract.

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

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

Виділення API client і resource methods

Shared `RequestSpecification` виноситься в client/configuration method, а resource operations — у methods з domain names, наприклад create/find pet. Тест залишає сценарій і assertions, transport details переходять в client. Рефакторинг починається після working example, а не з speculative framework. Назва class може бути `Client`, `Controller` чи `Service`; важливіше, щоб він відповідав одному resource/service boundary.

API: що тестувати та як написати перший тест →

Java · Advanced: API-автоматизація · 2:00:00–2:12:28

Token lifecycle у test runner і controllers

Token можна отримати в suite/JUnit lifecycle і передати в base controller. Це прибирає repeated login з кожного test і зберігає transport setup в одному місці. Один global token доречний лише для одного immutable identity без parallel mutation. Для tests різних users/scopes потрібен session/token per test context або safe cache з expiry/refresh — інакше паралельні tests впливатимуть один на одного.

OAuth 2.0 і конфігурація →
Запитати в чаті про «controllers» →