GraphQL resolver
Server-side function для schema field, яка отримує value з application code, database або downstream service. GraphQL не виконує service discovery самостійно.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Migration mapping checklist
Оберіть одну DTO з проєкту.
Для кожного field зафіксуйте source entity/service, mapping rule, nullability, required status, serializer behavior і regression test.
Додайте один gateway header, який має пройти до внутрішнього service.
Mapping table і один перевірений routing contract.
Намалювати test-aware service map
Вибрати один user flow і намалювати client, gateway, services, databases і brokers.
Позначити synchronous і asynchronous contracts, state setup і failure boundaries.
Для кожної boundary записати одну contract check і одну end-to-end check.
Одна діаграма, за якою видно, де готувати data і як локалізувати test failure.
Шари від таблиці до API response
На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по `taxId` чи додаткові атрибути. Поля на кшталт `createdAt`, `updatedAt` і `deletedAt` можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.
Gateway і вкладена архітектура
Gateway може бути зовнішньою обгорткою над одним або кількома services. Тому один квадрат на high-level diagram може приховувати власну базу, декілька внутрішніх services і нові integrations. Кожен із цих components можна «наблизити» і знову побачити нову архітектуру. На новому проєкті варто попросити lead або developer намалювати таку service map, а потім уточнювати data stores і взаємодії. Це безпосередньо впливає на test design: де готувати state, які контракти перевіряти і де локалізувати падіння.
Перейменування полів і похідні значення
Навіть просте перейменування `surname` на `lastName` зачіпає кілька шарів: database/entity, зовнішній service, mapping і DTO. Якщо API має повертати `fullName`, service може формувати його з `name` та `lastName`; отже, механічне копіювання одного поля дасть синтаксично валідний, але семантично неправильний response. Що більше полів і mapping rules, то вищий ризик пропустити зв’язок або зберегти не те значення. Тести мають перевіряти не лише наявність response, а й коректність значень після всіх перетворень.
Мова як спосіб знайти правильний test level
Ширше знання стеків допомагає не дублювати один сценарій на найдорожчому рівні. Mobile behavior іноді краще перевірити XCTest або Kotlin test; business rule — backend integration test; а лише критичний cross-service flow залишити системним E2E. Вибір залежить від архітектури: частина failures виникає не в service, а в API gateway чи infrastructure. Тому «перенести все вниз» так само некоректно, як перевіряти все через UI. Потрібно розуміти, який рівень реально спостерігає ризик.
REST, status codes і централізовані errors
Для API automation потрібно окремо вивчити REST semantics: methods, resources, типові status codes і їхню очікувану поведінку. Public endpoints зазвичай оптимізовані для frontend або зовнішніх clients, private endpoints можуть обслуговувати внутрішню service-to-service communication і мати інший контракт. Самого HTTP status недостатньо. Централізований error handling має повернути consumer стабільний internal error code і зрозуміле пояснення: якого поля бракує або яке значення невалідне. Власні HTTP status codes на кшталт `600` не замінюють нормального error contract.
API gateway і внутрішні services
Клієнт звертається до одного зовнішнього API gateway, хоча за ним працюють окремі user/account та appointment services. Gateway перетворює зовнішній route і проксіює request у внутрішню мережу до відповідного service; зовнішнє й внутрішнє найменування ресурсу може відрізнятися. Service, у свою чергу, може читати кілька tables, звертатися до інших services, виконувати filters і mappings, а controller повертає сформовану DTO. Тому response одного endpoint залежить не від одного методу, а від усього ланцюжка.
Routing-регресії та роль API tests
Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне `401`, бо потрібний header загубився між ними. API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.
Ланцюжки сервісів і технічний борг
Один і той самий service може бути producer для одного виклику і consumer для іншого. Тому response, яку отримує frontend, може залежати від кількох внутрішніх викликів. Чиста теоретична модель не завжди збігається з production: дедлайни змушують команду накопичувати technical debt і порушувати ідеальні межі. Тестувальник має досліджувати фактичні зв’язки, а не покладатися лише на назви сервісів.
Дії, browser protocol і порівняння з WebDriver
[Дивитися з 09:10](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=550s). Для `click`, `dblclick`, `fill`, evaluate та інших actions у команду входять target locator, parent frame і options. Browser-side automation layer виконує пошук у правильному контексті та повертає результат або error. На прикладі Chromium автор пояснює роль Chrome DevTools Protocol і показує інструмент командного рядка, який також керує browser через локальний service. Для порівняння Selenium client зазвичай спілкується з browser-specific WebDriver через W3C WebDriver protocol, а driver уже координує browser. В обох випадках test code не клікає DOM напряму: між ним і browser є protocol та процес, що виконує команди.
Комбінований 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.