GraphQL operation
Query є read-only fetch, mutation — write followed by fetch, subscription — long-lived event-driven request. Selection set визначає fields, які client очікує у response.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
GraphQL Specification — September 2025
Нормативні definitions для query, mutation, subscription і selection set.
Вступ до API-автоматизації → Першоджерело ↗parameter ID
Читабельний identifier конкретного parameter set, заданий через ids, callable або pytest.param(..., id=...). Він з'являється у collection і failure output.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
Set, унікальність і порівняння наборів
`set` зберігає унікальні значення та не обіцяє бізнес-порядок. Він корисний для roles, permissions і видалення дублікатів, а також для перевірок subset/difference. Фігурні дужки без `key: value` створюють set; словник відрізняється наявністю ключів і двокрапок.
`for` для list і set
`for item in collection` по черзі підставляє кожен елемент у змінну циклу. Це типовий спосіб обійти Playwright locators, Selenium elements, test cases або users. List зберігає порядок і дублікати; set прибирає дублікати, але його порядок не слід використовувати як частину очікуваної поведінки тесту.
Нормалізація та set comprehension
`{email.lower() for email in emails}` одночасно переводить email у lower case й прибирає дублікати. Це корисно для даних із CSV або UI, де регістр може відрізнятися. Якщо важливий порядок або треба зберегти дублікати, слід обрати list comprehension замість set.
`not`, `in` і `not in`
`not errors` є короткою перевіркою порожнього списку. `browser in supported_browsers` і `browser not in supported_browsers` прямо виражають membership та прибирають ручний цикл. Для allowlist status codes зручно використовувати set: `status_code in {200, 204}`.
Стабілізація сценарію та практичне завдання
Явні умови застосовуються до success message після логіну та до заголовка проєкту після навігації. Тепер падіння точніше описує проблему: не «клік не спрацював», а очікуваний елемент не став видимим за відведений час. Для відтворюваного layout driver може максимізувати вікно або встановити фіксований розмір через `set_window_size()`. Локальний курсор також варто прибирати з області браузера: hover-стани, підказки та підсвічування можуть змінити DOM або перекрити ціль. У CI цей фактор зазвичай відсутній, але viewport усе одно треба задавати явно. Практика після уроку: повторити простий Selenium-тест від fixture до входу й пошуку, а потім замінити одноразові `is_displayed()` у точках переходу на explicit waits із locator-based conditions.
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 малою і довіреною.