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

Дані, які бачить користувач, приходять з backend services, тому UI scenario часто можна розкласти на більш швидкі API checks. Спочатку треба з’ясувати API maturity: чи є specification, чи вона актуальна, як frontend реально викликає endpoints.

Якщо documentation немає або їй не можна довіряти, browser DevTools/Network дає фактичні URL, method, headers, payload і response. Це джерело для discovery, але не заміна погодженого contract.

Автор розбирає Swagger/OpenAPI descriptions і JSON як мову обміну між clients та backend. Тип, format, required fields, arrays і dates важливі не менше за business value.

Окрема тема — перетворення дат і numbers між database, backend і frontend. Якісний test design залежить від розуміння цих transformations; black-box response assertion може не показати, на якому рівні виник defect.

Створюється Java/Gradle project з group/package naming, JUnit Platform і dependencies. Відео використовує Java 11/17 і пояснює різницю Maven та Gradle як build tools.

Repositories та artifact storage потрібні не лише для third-party libraries: компанія може публікувати власні clients і test artifacts. Точні dependency versions мають бути pinned і відтворювані на CI.

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 перевіряються явно.

Для request body генеруються identifier, name та інші data. Faker прибирає hard-coded duplicates і допомагає покрити більше values.

Водночас randomness не має ховати failure. Згенеровані values потрібно логувати або мати deterministic seed, інакше CI failure буде важко відтворити.

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.

Після create виконується GET і response data порівнюються з generated input. Помилки 400/500 розбираються через actual request/response, а не через здогад.

Відео навмисно залишає неідеальний demo API і live debugging. Це добре показує межу між client defect, unstable shared test API і real server defect.

Request і response логуються так, щоб failure міг відтворити розробник. RestAssured filters дають central logging seam, а Allure integration може прикріпити HTTP exchange до test step.

Логи можуть містити credentials, tokens і personal data. У production-like test environments потрібне masking/redaction; «логувати все» — лише діагностичний старт, а не безпечний дефолт.