HTTP status code
Тризначний code у межах 100–599, який повідомляє result HTTP request; 600 і вище не є valid HTTP status codes.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
WebDriver remote end
Сторона W3C WebDriver protocol, яка приймає HTTP command від local end, виконує browser automation operation і повертає HTTP response.
3. Selenium vs Playwright - яка різниця →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-автоматизації →APIRequestContext
Playwright HTTP client для прямих API-запитів, зокрема підготовки server-side state перед відкриттям web application.
3. API preconditions →RFC 6585: 429 Too Many Requests
Відокремлює HTTP rate-limit contract від довільної fixed delay у тесті.
2. Pytest fixtures, playwright fixture, прараметризація тестів → Першоджерело ↗RFC 9110 §15: Status Codes
Нормативні semantics і valid range HTTP status codes.
Вступ до API-автоматизації → Першоджерело ↗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.
`if`, `elif`, `else` і межі status codes
`if` запускає блок лише для truthy умови, `elif` перевіряє наступний варіант, а `else` покриває залишок. Для HTTP ranges треба явно визначати inclusive/exclusive boundaries: success зазвичай `200 <= code < 300`, client error — `400 <= code < 500`, server error — `500 <= code < 600`.
Порядок гілок і семантика HTTP response
Ланцюг `if/elif` зупиняється на першій істинній умові, тому вузькі діапазони не повинні бути перекриті ширшими попередніми умовами. Status code описує результат HTTP-обробки, але не гарантує відсутність side effects: система могла записати дані, а потім повернути `500`. Тест має перевіряти і response, і важливий стан системи.
Selenium WebDriver, explicit waits і ширша matrix
Selenium 4 використовує стандартизований W3C WebDriver protocol. Client binding надсилає HTTP-команди WebDriver endpoint, а browser-specific driver виконує їх у Chrome, Firefox, Edge, Safari чи іншому підтримуваному браузері. У старішому Selenium 3 застосовувався JSON Wire Protocol. У класичному Selenium flow перед click або input часто використовується explicit wait: client повторно перевіряє умову на кшталт visibility або clickability, а після її виконання надсилає окрему action command. Це створює більше round trips, особливо коли browser session віддалена. Сильна сторона Selenium — широка екосистема vendor drivers і remote providers. Якщо навіть невелика частка користувачів певного браузера означає сотні тисяч людей або браузер входить у договірну support matrix, таке покриття не можна відкидати лише через повільніший test run. У Python-проєкті технічно можна мати і Playwright, і Selenium tests під pytest: Playwright для основного functional suite, Selenium — для вузької cross-browser перевірки. Це виправдано лише реальною вимогою, бо два automation stacks подвоюють dependency, fixture та maintenance surface.
Consumer, producer і REST resources
Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.
Моноліт, модульний моноліт і мікросервіси
У моноліті business logic, email, SMS, persistence та integrations розгортаються як один application. Це не є автоматично погано: добре структурований моноліт простіший у розробці і не платить network latency за кожен внутрішній виклик. Модульний моноліт розділяє functionality всередині одного deployment і може зберігати окремі data boundaries. Мікросервісна архітектура виносить ці частини у незалежні services, але додає HTTP, serialization, handshakes, deployment і distributed failure modes.
`BaseController`, headers, errors і logging
`BaseController` приймає base URL і JWT, формує спільні headers `Authorization` і `Content-Type: application/json`, виконує HTTP-запит і піднімає exception для неуспішного статусу. Методи `get`, `post` і `put` повторно використовують цю поведінку; `post` і `put` додатково приймають request body. Запити варто логувати, щоб під час падіння було видно method, endpoint і контекст виклику. Для `requests` таке logging додають явно; `HTTPX` має власний logging namespace, тому конкретна реалізація залежить від обраного client.
Мінімальний API client і pytest fixture
Клієнт містить лише потрібні операції: authentication і `get_projects`. У прикладі використано `httpx`, хоча для синхронного сценарію стандартний для проєкту HTTP-клієнт також достатній; не слід додавати dependency лише через згенерований AI-код. Авторизований client надається через pytest fixture. JWT кешується всередині instance, щоб кілька endpoint calls одного тестового lifecycle не повторювали login. Спочатку окремі API-тести перевіряють успішну авторизацію та непорожній список проєктів.
Local і remote execution
Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.
REST і GraphQL уже дають словник для API automation
У REST структура починається з resources та HTTP methods. `Pet`, `Store` або `User` задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request. У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.