Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Для одного POST endpoint опишіть immediate response assertion і спосіб перевірки eventual result.
Додайте resource-schema assertions і один business-flow assertion.
Позначте, який тест локалізує кожен failure.
Таблиця з чотирма checks, test level і failure signal.
Перед запитанням або прикладом приберіть domains, secrets, персональні дані й identifiers зі screenshots, HTML та endpoint fragments.
Практика курсу на YOY, домашні завдання та формат ПМП →Projects endpoint повертає колекцію проєктів із title та id. Для прикладу обирається проєкт Manufacture Light, у межах якого потрібно створити test suite. Початковий лінійний сценарій розділяється на methods для login, projects і suites. Кожен method отримує тільки потрібні йому дані: token, project name/id та payload. Це підготовка до винесення API-логіки в controllers.
Перший 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.
Перша практична ітерація — отримати контрольований доступ до наявного скрипта створення користувачів. Скрипт може приховувати складну синхронізацію з державними або сторонніми системами та створювати валідний mocked-профіль для тестового середовища. Далі варто параметризувати потрібний тип і стан користувача та, за потреби, запускати provisioning за розкладом. Кращий довгостроковий шов — test-support endpoint або інший сервісний контракт для створення сутності з унікальним email та потрібними атрибутами. Його можна спочатку викликати з Postman, Insomnia, Bruno чи IDE HTTP client, а потім перенести в test setup. Endpoint видалення не є автоматично безпечним: треба врахувати зв'язки даних і реальну модель lifecycle.
Для 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.
Перед автоматизацією 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.
[Дивитися з 06:10](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=370s). У реальній архітектурі browser звертається до API gateway, той перевіряє authentication та authorization, передає запит backend-сервісу, а backend отримує шаблон або ініціює відправлення через інший сервіс. Invite token має бути згенерований правильним компонентом, переданий без зміни й мати визначений TTL. Якщо контракт нечіткий, один сервіс може додати зайвий або захардкоджений token, після чого формально валідний request завершується невалідним invite. Перевірка лише зовнішньої специфікації endpoint не знаходить помилку в розподілі відповідальності між сервісами.
Після узгодження behavior загальний scenario треба декомпозувати. Frontend task описує component, validation і UI states; backend task — endpoint, contract і business rule; test task — ризики й потрібне coverage. Для інженера прямий технічний опис часто коротший і точніший за повторення кожної умови через `Given/When/Then`. Проблема починається, коли один формат примусово використовують для всіх ролей. Business не має керувати деталями automation code, а automation engineer не повинен перекладати вже зрозумілий technical contract у довший Gherkin лише для формальної відповідності процесу.
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.
[Дивитися з 08:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=480s). YOY навмисно лишається живим продуктом із evolving behavior, щоб учні бачили не стерильні приклади, а неоднозначні UI states, responsive issues, calendars, images, links, QR та chat/network mode. Помічену неточність не варто автоматично списувати на «специфіку»: вона може розростися в regression. Питання про робочі проєкти треба анонімізувати — прибирати domains, secrets, персональні дані та інші identifiers зі screenshot, HTML або endpoint fragment.
[Дивитися з 08:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=480s). Досвідчений engineer із точним plan може реалізувати frontend, backend і частину deployment pipeline, використовуючи готову design system та API contract. Frontend має знати, який resource і endpoint запросити; backend — який response повернути; shared components і design tokens дають повторюваний UI. AI допомагає заповнити реалізацію, але не визначає самостійно правильні boundaries і product behavior.