← Java

Конспект і таймкоди

0:00

Дослідження API, frontend і авторизації

Перед автоматизацією API потрібно дослідити, як із ним працює frontend. Network tab дає фактичні requests навіть тоді, коли документації немає або вона застаріла. На прикладі sign-in показано POST зі status 302, що може свідчити про Backend for Frontend або gateway із власною логікою.

Форма відправляє email, password, ознаку remember me і authenticity token. Якщо API не має окремого login endpoint, автотест може завантажити HTML, витягнути токен і відтворити application/x-www-form-urlencoded request. У відео натомість використовується задокументований API token/login flow. Автор окремо показує, що payload може бути form data або JSON.

5:14

Підключення RestAssured і структура тестів

До проєкту додається актуальна RestAssured dependency. Практичний сценарій складається з логіну, отримання проєкту і створення test suite, який пізніше можна використати як API precondition для UI-тесу.

Якщо UI- та API-теси живуть в одному проєкті, їх варто рознести за packages web і api. Перший API-тест створюється як окремий Java class і спочатку збирає весь flow в одному місці.

7:38

`given`, `when`, `then` і login request

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.

10:50

Логування і витягування token з response

log().all() показує request і response, включно з form parameters; prettyPrint() дає компактніший вивід body. Повні headers потрібні лише тоді, коли діагностика вимагає більше, ніж response body.

Щоб використати token в наступних requests, response переводиться в extract mode, а значення зчитується через JsonPath getString. Отриманий token зберігається у змінну для виклику projects API.

14:47

`RequestSpecification`, authorization і content negotiation

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, тому потрібний набір перевіряється експериментально.

20:38

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

Projects endpoint повертає колекцію проєктів із title та id. Для прикладу обирається проєкт Manufacture Light, у межах якого потрібно створити test suite.

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

24:30

Витоки стану у RestAssured і пошук правильного endpoint

Перший 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.

30:06

Створення suite через JSON body

Згідно з API-документацією додається POST method для створення test suite. Його назва узгоджується з назвою операції в документації, а token, project id і body передаються явно.

Для першого варіанта JSON записується в Java text block і передається як request body. Щоб повторні запуски не створювали однакові назви, шаблон форматується через String.format, а до title додається current timestamp.

35:40

`Content-Type`, API defect і стабільна specification

Перша спроба не спрацьовує, доки request явно не позначено як JSON через Content-Type. Після цього suite створюється і видно в UI. Endpoint повертає 200, хоча для create operation очікується 201; автор називає це API defect.

Отриманий flow вже можна використати як API precondition для UI-тесів. Ключове обмеження RestAssured: reusable configuration має повертатися з method як новий instance для кожного request, а не зберігатися як mutable shared object.