Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
До проєкту додається актуальна RestAssured dependency. Практичний сценарій складається з логіну, отримання проєкту і створення test suite, який пізніше можна використати як API precondition для UI-тесу. Якщо UI- та API-теси живуть в одному проєкті, їх варто рознести за packages `web` і `api`. Перший API-тест створюється як окремий Java class і спочатку збирає весь flow в одному місці.
Перший request до suites повертає `400`, бо повторно використана mutable `RequestSpecification` зберегла form parameters від login request. RestAssured накопичує налаштування у стані specification, тому вона не повинна мутуватися і перевикористовуватися між різними requests. Виправлення — повертати нову specification із factory method для кожного request. Після цього уточнюється endpoint path: запит має містити API prefix, project id і suites resource. Потім `GET` повертає список suites з їхніми id, type і title.
RestAssured дає BDD-style `given`/`when`/`then`. У request configuration задаються base URI/path, headers, query/form parameters, body і logging; HTTP method запускає виклик, а response validation перевіряє result. `Content-Type` описує request body, `Accept` — бажаний response format. `415 Unsupported Media Type` і інші `4xx` часто свідчать про помилку request contract, тому headers перевіряються явно.
Спільна 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.
RestAssured надає BDD-синтаксис `given`/`when`/`then`. У `given` окремо задаються `baseUri`, `basePath`, request parameters і інша підготовка; path радять зберігати без завершального slash, а slash додавати на початку endpoint path. Для login request email і password передаються як `formParam`, після чого виконується `POST`. Спочатку очікується status `200`, а response body має містити token.
Java generator може будувати client на різних HTTP libraries. Відео експериментує з RestTemplate та RestAssured, пояснюючи, що library choice впливає на generated signatures, exceptions і dependencies. Немає універсального найкращого client. Для tests важливі controllable requests, raw negative responses, logging/masking і compatibility з project stack.
Для сталого логування request і response додається custom filter, який реалізує RestAssured `OrderedFilter`. Він логує request до виклику і response після нього, а також не намагається виводити порожнє body. Filter передається в base API configuration, тому всі controllers мають однакову діагностику. Лог показує розбіжності між create і list responses: наприклад, labels в одному response мають інше значення, а description не повертається так, як очікувалося. Частина помилок належить не DTO, а неідеальному API contract.
Request і response логуються так, щоб failure міг відтворити розробник. RestAssured filters дають central logging seam, а Allure integration може прикріпити HTTP exchange до test step. Логи можуть містити credentials, tokens і personal data. У production-like test environments потрібне masking/redaction; «логувати все» — лише діагностичний старт, а не безпечний дефолт.
`log().all()` показує request і response, включно з form parameters; `prettyPrint()` дає компактніший вивід body. Повні headers потрібні лише тоді, коли діагностика вимагає більше, ніж response body. Щоб використати token в наступних requests, response переводиться в extract mode, а значення зчитується через JsonPath `getString`. Отриманий token зберігається у змінну для виклику projects API.
`RequestSpecification` зберігає спільні налаштування request: `baseUri`, `basePath`, logging та інші параметри. Окремі specifications можуть описувати різні domains або request types, наприклад multipart. У тесті синтаксичні `when` і `then` можна опусти, якщо після HTTP method одразу обробляється `Response`. Token передається в authorization header. У RestAssured є спеціалізовані auth methods, але в прикладі header задається явно. `Content-Type` описує формат request body, `Accept` — бажаний формат response. Неправильний або відсутній header може дати `4xx`, тому потрібний набір перевіряється експериментально.