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-over-HTTP не обмежується POST і status 200
Current GraphQL-over-HTTP draft requires POST support, permits GET for query operations, forbids GET for mutations and defines non-200 status handling. Тому transport contract треба тестувати за media type і operation, а не очікувати 200 для кожної відповіді.
Точну транспортну специфікацію відео не називає; перевірено проти current draft 2026-07-31.
Вступ до API-автоматизації →GraphQL Specification — September 2025
Нормативні definitions для query, mutation, subscription і selection set.
Вступ до API-автоматизації → Першоджерело ↗SQL parameter binding
Передача values окремо від SQL statement через placeholders і driver API. Це зберігає type handling і не складає query через string formatting.
Автомтизація баз даних та що з тим робити та що знати →Ізольований DB setup із parameter binding
Використовує in-memory database, connection context manager і placeholders без зовнішніх dependencies.
Assertion проходить; query повертає row (1,).
GraphQL як агрегатор даних
У GraphQL client зазвичай звертається до одного endpoint і в request описує потрібні fields та зв’язки. Queries читають дані, mutations змінюють їх. Якщо екрану потрібні user і всі його pets, GraphQL layer сам визначає, які downstream services викликати і як звести результат. Для тесів важливо знати цей internal mapping. Тоді покриття можна розділити за downstream service і полем, а при падінні однієї частини очікувати точний набір failures, а не безадресне падіння всіх API-тесів.
`WebDriverConditions` і перевірки URL
Умови WebDriver дозволяють перевіряти URL, title, cookies та інший стан браузера. Автор застерігає від беззмістовної перевірки випадкового фрагмента URL: вона подібна до перевірки елемента лише за індексом і не доводить, що користувач отримав потрібний результат. URL-condition виправданий для redirects або query parameters із предметним значенням — наприклад, коли треба підтвердити джерело переходу з Google, Hotline, соціальної мережі чи іншого метапошуку. В інших випадках краще чекати спостережуваний стан сторінки через предметний `isLoaded`-метод.