GraphQL operation
Query є read-only fetch, mutation — write followed by fetch, subscription — long-lived event-driven request. Selection set визначає fields, які client очікує у response.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірка створеної сутності в event-driven системі
Питання учасника: якщо `POST` повернув `200 OK` із порожнім body, чи достатньо цього для перевірки створення сутності. В event-driven архітектурі успішна відповідь може означати лише прийняття команди, а фактичний запис з’явиться пізніше, тому наступний `GET` перевіряє спостережуваний результат. Лектор розділяє два типи coverage: сценарій для конкретного ресурсу та повний business flow. CRUD/resource test локалізує помилку в операціях над сутністю; сценарний тест перевіряє, що ланцюжок бізнес-дій працює цілісно. Один тип не замінює інший, бо дефект може проявитися лише на конкретному стику.
Event-driven communication і message broker
Сервіс orders може публікувати подію в Kafka або інший broker, а consumer — зчитувати її і оновлювати status. Асинхронна queue допомагає приймати spikes швидше, ніж downstream встигає повністю опрацювати кожен order. Це не усуває навантаження, а змінює його форму і час. Для тесів з’являються окремі питання: чи опубліковано подію, чи вона була опрацьована, що відбувається з retries, duplicates і відкладеною consistency.
Комбінований UI/API/DB framework і архітектурний рівень
Framework, який одночасно керує UI, API та DB, вимагає чітких lifecycle і ownership: окремі clients, ізольовані test data, безпечний connection pool, cleanup і коректна робота в parallel. Додавати всі рівні до кожного тесту не потрібно; кожен сценарій має використовувати найнижчий seam, який доводить потрібну поведінку. На senior-рівні додаються system architecture, protocols, caching і concurrency. В event-driven системах доводиться спостерігати Kafka, RabbitMQ або інший broker, чекати eventual consistency та корелювати події. Stub service корисний для контрольованих failure/edge cases, але не замінює невеликий набір справжніх integration tests.