GraphQL operation
Query є read-only fetch, mutation — write followed by fetch, subscription — long-lived event-driven request. Selection set визначає fields, які client очікує у response.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
GraphQL Specification — September 2025
Нормативні definitions для query, mutation, subscription і selection set.
Вступ до API-автоматизації → Першоджерело ↗Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
`ElementsCollection`, масиви та Java Collections Framework
Знайдені плитки проєктів зберігаються у змінній типу `ElementsCollection` — власному типі Selenide, пристосованому до роботи з набором UI-елементів. Поруч автор порівнює масиви з `List` і `Set`: колекції мають готові операції для обходу, фільтрації, пошуку, сортування, додавання та очищення. Масив може бути трохи компактнішим або швидшим, але для UI-автотесту ця різниця зазвичай губиться на тлі звернень до браузера. Читання значення з пам’яті триває незрівнянно менше, ніж отримання тексту зі сторінки локально, у Jenkins або через BrowserStack. Тому для звичайних тестів важливіші зручність і читабельність; мікрооптимізації мають сенс лише після вимірювання реальної проблеми, наприклад коли підготовчі дії спотворюють performance test. Для розміру масиву використовується `length`, а для колекції — метод `size()`. IDE підказує доступні операції та може запропонувати stream, але на цьому етапі урок радить залишатися з простішими колекційними API.
Generated source sets і clean builds
Gradle і IDE мають знати, що generated directory є Java source root. IDE indexing може вимагати explicit generated-source marking, але command-line build не має залежати від manual IDE action. `clean` видаляє generated output, а build відновлює його зі specification. Це перевіряє, що repository не приховує uncommitted/manual fixes generated code.
CI pipeline, real devices і мінімум E2E
Рекомендована послідовність: static analysis і developer tests, build artifact, backend/environment tests, deployment на test/stage, platform integration tests, малий critical E2E set. Simulators/emulators дають швидкий feedback, representative real devices — confidence в hardware/OS integrations. Appium-style cross-platform E2E варто залишити для кількох user journeys, які справді мають пройти весь stack. Backend і frontend/mobile component coverage не зникають; вони роблять E2E suite малою і довіреною.