GraphQL operation
Query є read-only fetch, mutation — write followed by fetch, subscription — long-lived event-driven request. Selection set визначає fields, які client очікує у response.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
RFC 9110: HTTP Semantics
Уточнює значення 200 OK, 202 Accepted і response content для POST.
Матриця перевірок створення ресурсу
Для одного POST endpoint опишіть immediate response assertion і спосіб перевірки eventual result.
Додайте resource-schema assertions і один business-flow assertion.
Позначте, який тест локалізує кожен failure.
Таблиця з чотирма checks, test level і failure signal.
Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
Що змінилося після запису
У відео 200 OK використано як приклад response, після якого сутність у distributed system ще може потребувати окремої перевірки через GET.
За RFC 9110 стандартним сигналом незавершеної асинхронної обробки є 202 Accepted; 200 OK означає, що request succeeded. Реальний тест має спиратися на контракт конкретного API й не виводити completion semantics лише зі status class.
RFC 9110 published 2022-06
Міграція бази даних і тестування даних →reCAPTCHA response token
Короткоживучий одноразовий token, який backend перевіряє server-side; Google вказує двохвилинний строк дії та заборону повторної verification.
Антибот-захист у контрольованих автотестах →Response DTO і перша deserialization
З реального JSON response генерується `SuiteResponse` із nested data, attributes та relationships. RestAssured response переводиться в Java class через `extract().as(...)`. Після цього test отримує autocomplete для `getData()`, attributes, id, type і title замість string paths. Перший запуск виявляє, що response не приводиться до згенерованої моделі автоматично. Відео залишає цей невдалий прохід видимим, щоб показати реальну складність великих DTO і Jackson configuration.
Логування і витягування token з response
`log().all()` показує request і response, включно з form parameters; `prettyPrint()` дає компактніший вивід body. Повні headers потрібні лише тоді, коли діагностика вимагає більше, ніж response body. Щоб використати token в наступних requests, response переводиться в extract mode, а значення зчитується через JsonPath `getString`. Отриманий token зберігається у змінну для виклику projects API.
Fluent DTO і перші response assertions
Lombok `@Accessors(chain = true)` дозволяє ланцюжком викликати setters, а `@Data(staticConstructor = "of")` — створювати object без явного `new`. У демонстрації це скорочує вкладену підготовку request data порівняно з розгорнутим builder. Після створення suite тест має перевірити, що response містить згенерований title. Перший варіант зчитує його з RestAssured response через `jsonPath().getString(...)`; для endpoint, який повертає масив suites, потрібно отримати list titles, а не один string.
Request DTO і response DTO
Одна model для request і response придатна лише тоді, коли wire shapes справді збігаються. Якщо response має generated id/timestamps або request забороняє server-owned fields, потрібні separate `PetRequest` і `PetResponse`. Невдала deserialization найчастіше означає incorrect DTO shape/type або Jackson configuration. Виправлення — звірити модель з real JSON/OpenAPI contract, а не додавати random annotations, доки exception не зникне.
Jackson Databind, `@JsonProperty` і різні response shapes
Для Jackson2 deserialization явно підключається Jackson Databind. Поля JSON на кшталт `created-at`, які не відповідають Java naming conventions, мають бути явно зв’язані з fields через `@JsonProperty`. Виявляється ще одна контрактна різниця: create endpoint повертає один data object, а list endpoint — array таких objects. Одна й та сама field type не може безпечно представляти обидва shapes, тому моделі розділяються на single response і list response.
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.
Fluent response assertions і business-readable API
Над `Response` будується small fluent wrapper: status, typed body, field/domain assertions, завершення chain. Це дає тесту domain vocabulary і прибирає repeated parsing. Важливо не сховати expected behavior за великим «validateEverything». Fluent method має виражати одну observable property і давати specific failure.
Очікування network events і API mocking
Playwright може чекати завершення request або появи response під час конкретної дії. У власній обгортці автора це оформлено як `clickWithWaitForRequestFinished`: всередині викликається Playwright network wait, а дія click передається callback-ом. У документації також показані перехоплення request/response, `route` і `fulfill`, тобто можливість змінити або підмінити API response. У відео ці приклади не реалізуються повністю: головна мета — показати доступний механізм і запропонувати дослідити його в домашній роботі. Network wait корисний не лише для синхронізації UI, а й для перевірки analytics чи інших events, що мають бути відправлені після кліку. Автор радить зберігати однаковий читабельний порядок у тестах — дія, а потім очікуваний результат — навіть якщо базовий API описує wait до callback-дії.
Шари від таблиці до API response
На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по `taxId` чи додаткові атрибути. Поля на кшталт `createdAt`, `updatedAt` і `deletedAt` можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.
Перейменування полів і похідні значення
Навіть просте перейменування `surname` на `lastName` зачіпає кілька шарів: database/entity, зовнішній service, mapping і DTO. Якщо API має повертати `fullName`, service може формувати його з `name` та `lastName`; отже, механічне копіювання одного поля дасть синтаксично валідний, але семантично неправильний response. Що більше полів і mapping rules, то вищий ризик пропустити зв’язок або зберегти не те значення. Тести мають перевіряти не лише наявність response, а й коректність значень після всіх перетворень.