Урок замінює довгу UI-підготовку API precondition: клієнт авторизується в Testomat.io Public API, отримує список проєктів, перетворює JSON на типізовані dataclasses і передає `project_id` у UI-тест. Після цього сценарій одразу відкриває потрібний проєкт і перевіряє створення test suite/test case, не створюючи проєкт через UI щоразу.
Примітка: конспект укладено за автоматичними українськими субтитрами; назви API, JWT, OpenAPI, pytest і Playwright нормалізовано за контекстом відео.
Після цього уроку ви зможете
Знайти потрібну OpenAPI operation замість генерації клієнта для всього API.
Підготувати server-side test state через APIRequestContext до UI-переходу.
Перетворити мінімальну API-відповідь на типізовану dataclass.
UI-сценарій має пройти довгий user journey лише для того, щоб дістатися стану, який перевіряє тест. Якщо створення або пошук проєкту не є предметом перевірки, його можна підготувати через backend API й одразу відкрити сторінку за project_id.
Спочатку треба дослідити Network, але server-side rendering може приховати окремі XHR-запити. Тоді джерелом контракту стає офіційна OpenAPI/Swagger документація backend, а не припущення за URL інтерфейсу.
Практика
Заміна UI setup на API precondition
Знайдіть одну OpenAPI operation за operationId.
Напишіть окремий API contract test для status і мінімальної response schema.
Передайте отриманий ID у page object і приберіть лише зайві UI setup-кроки.
Результат: API test окремо перевіряє контракт, а UI test починається з готового server-side state й перевіряє свій основний сценарій.
OpenAPI JSON/YAML можна передати AI-агенту, але велика специфікація легко перевищує корисний контекст. Не варто просити згенерувати клієнт для всього API, якщо зараз потрібна одна операція.
Практичний процес: знайти в документації endpoint, його operationId (getProjects), спосіб авторизації, parameters і response schema; потім дати агенту лише цей контракт і конкретну задачу.
Що змінилося після запису
`getProjects` не підтверджено як current `operationId`
У відеоУ відео в завантаженій OpenAPI specification знайдено operation ID getProjects.
АктуальноПоточна публічна документація Testomat.io підтверджує endpoint отримання проєктів, але не показує operationId=getProjects; цей identifier лишається властивістю snapshot із відео, доки його не підтверджено в current OpenAPI document.
Перевірено 2026-07-31
Термін
operationId
Необов’язковий OpenAPI identifier; якщо він присутній, має бути case-sensitive і унікальним серед operations, а інструменти можуть використовувати його як стабільне ім’я.
У Testomat.io API token не обов’язково є готовим bearer token для всіх запитів: його може бути потрібно обміняти на JWT через login endpoint. Урок демонструє, чому тип авторизації треба перевіряти за документацією та реальною відповіддю API.
Секрет зберігається в environment variable, а не в коді. Постійне використання email/password додає зайвий запит і ширший секрет; token flow варто обирати лише якщо backend справді його підтримує.
Увага
Секрети лише через environment
API token, email і password не повинні потрапляти в код, конспект або Git; клієнт має читати потрібний секрет із runtime environment.
Термін
APIRequestContext
Playwright HTTP client для прямих API-запитів, зокрема підготовки server-side state перед відкриттям web application.
Термін
Testomat.io Public API reference
Поточна rendered reference показує login flow і endpoint отримання проєктів; exact authentication header слід перевіряти за чинною документацією та реальною відповіддю API.
Клієнт містить лише потрібні операції: authentication і get_projects. У прикладі використано httpx, хоча для синхронного сценарію стандартний для проєкту HTTP-клієнт також достатній; не слід додавати dependency лише через згенерований AI-код.
Авторизований client надається через pytest fixture. JWT кешується всередині instance, щоб кілька endpoint calls одного тестового lifecycle не повторювали login. Спочатку окремі API-тести перевіряють успішну авторизацію та непорожній список проєктів.
Raw dict змушує пам’ятати рядкові ключі й не дає надійного autocomplete. Response перетворюється на невелику Project dataclass із фактично потрібними полями, насамперед id та attributes.
Десеріалізація має відповідати реальній response schema. Не потрібно моделювати всі поля API «про запас»: для поточного vertical slice достатньо тих, які читає тест, з явною помилкою при відсутньому обов’язковому значенні.
Приклад коду
Мінімальна typed projection API-відповіді
from dataclasses import dataclass
@dataclass(frozen=True)
class Project:
id: str
def parse_projects(payload: list[dict[str, str]]) -> list[Project]:
return [Project(id=item["id"]) for item in payload]
assert parse_projects([{"id": "p-1"}]) == [Project("p-1")]
Проєктує лише потрібне поле id замість поширення raw dictionary у UI-тест.
Очікуваний результат: Assertion завершується без помилки й повертає Project(id='p-1').
Тест викликає api_client.get_projects(), обирає цільовий проєкт і передає його id у метод project_page.open_by_id(). Це прибирає створення проєкту та пошук його URL через UI.
Перші падіння спричинені не API, а неправильним типом fixture: замість авторизованої page повернувся context або вже закрита сторінка. Setup повинен передавати саме ту page, яку створив і авторизував, без другого new_page().
Перевірка «порожній проєкт» не підходить для довільного existing project. Новий is_loaded спирається на стабільний sidebar/navigation, який існує і для порожнього, і для заповненого проєкту.
Далі тест відкриває dropdown створення артефактів і додає suite. Пошук locator уточнюється через видимий текст та структуру модалки, а не через крихкі CSS-класи іконки.
Модалки для Test і Suite мають схожий заголовок та форму. Спільний helper параметризується artifact_type, але лише там, де це справді одна поведінка; різні postconditions залишаються окремими й читабельними.
Після Save suite перевіряється за її назвою у списку. Демонстрація кілька разів падає через переплутані helpers і case-sensitive текст Suite, що показує цінність короткого red/green циклу для кожного locator.
API package містить client і мінімальні response models, fixture повертає авторизований client, а UI-тест використовує тільки потрібний endpoint для setup. Login token не перевипускається перед кожною операцією instance.
Практична вправа — реалізувати аналогічний precondition через наявний у проєкті HTTP client (requests, httpx або Playwright APIRequest), перевірити authentication окремо й лише потім під’єднати результат до UI-сценарію.