Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Java з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Java · Основний курс · 35:40–38:09

`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.

Rest Assured: базове використання →

Java · Основний курс · 5:14–7:38

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

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

Rest Assured: базове використання →

Java · Додаткові матеріали · 1:01:08–1:06:48

Динамічні й одноразові assertions

Selenide condition на кшталт `shouldHave(text(...))` очікує потрібний стан протягом певного часу, тоді як `getText()` плюс JUnit assertion читає значення лише один раз. Якщо frontend спочатку показує `0`, а потім `102`, одноразове читання може зробити тест flaky. Перед статичною числовою перевіркою слід хоча б дочекатися видимості або іншої надійної precondition; повторюваний parsing виноситься в один method.

Маленький рефакторинг і тестові дані у Java →
Запитати в чаті про «precondition» →