← Python мануфактура

Після цього уроку ви зможете

Конспект і таймкоди

0:00

API як швидша test precondition

UI-сценарій має пройти довгий user journey лише для того, щоб дістатися стану, який перевіряє тест. Якщо створення або пошук проєкту не є предметом перевірки, його можна підготувати через backend API й одразу відкрити сторінку за project_id.

Спочатку треба дослідити Network, але server-side rendering може приховати окремі XHR-запити. Тоді джерелом контракту стає офіційна OpenAPI/Swagger документація backend, а не припущення за URL інтерфейсу.

Практика

Заміна UI setup на API precondition

  1. Знайдіть одну OpenAPI operation за operationId.
  2. Напишіть окремий API contract test для status і мінімальної response schema.
  3. Передайте отриманий ID у page object і приберіть лише зайві UI setup-кроки.

Результат: API test окремо перевіряє контракт, а UI test починається з готового server-side state й перевіряє свій основний сценарій.

4:45

Звуження OpenAPI-специфікації до потрібної операції

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, а інструменти можуть використовувати його як стабільне ім’я.

8:20

Вибір способу авторизації

У 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.

13:55

Мінімальний API client і pytest fixture

Клієнт містить лише потрібні операції: authentication і get_projects. У прикладі використано httpx, хоча для синхронного сценарію стандартний для проєкту HTTP-клієнт також достатній; не слід додавати dependency лише через згенерований AI-код.

Авторизований client надається через pytest fixture. JWT кешується всередині instance, щоб кілька endpoint calls одного тестового lifecycle не повторювали login. Спочатку окремі API-тести перевіряють успішну авторизацію та непорожній список проєктів.

17:25

Типізована відповідь замість raw dictionary

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').

23:40

Передача `project_id` у page object

Тест викликає api_client.get_projects(), обирає цільовий проєкт і передає його id у метод project_page.open_by_id(). Це прибирає створення проєкту та пошук його URL через UI.

Перші падіння спричинені не API, а неправильним типом fixture: замість авторизованої page повернувся context або вже закрита сторінка. Setup повинен передавати саме ту page, яку створив і авторизував, без другого new_page().

29:25

Стабільний `is_loaded` і створення test suite

Перевірка «порожній проєкт» не підходить для довільного existing project. Новий is_loaded спирається на стабільний sidebar/navigation, який існує і для порожнього, і для заповненого проєкту.

Далі тест відкриває dropdown створення артефактів і додає suite. Пошук locator уточнюється через видимий текст та структуру модалки, а не через крихкі CSS-класи іконки.

37:50

Параметризація модалок і перевірка результату

Модалки для Test і Suite мають схожий заголовок та форму. Спільний helper параметризується artifact_type, але лише там, де це справді одна поведінка; різні postconditions залишаються окремими й читабельними.

Після Save suite перевіряється за її назвою у списку. Демонстрація кілька разів падає через переплутані helpers і case-sensitive текст Suite, що показує цінність короткого red/green циклу для кожного locator.

50:20

Підсумкова архітектура precondition

API package містить client і мінімальні response models, fixture повертає авторизований client, а UI-тест використовує тільки потрібний endpoint для setup. Login token не перевипускається перед кожною операцією instance.

Практична вправа — реалізувати аналогічний precondition через наявний у проєкті HTTP client (requests, httpx або Playwright APIRequest), перевірити authentication окремо й лише потім під’єднати результат до UI-сценарію.

Джерела та додаткові матеріали

  • OpenAPI Specification 3.2.0: Operation Object ↗OpenAPI Initiative · перевірено 2026-07-31

    Підтверджує й актуалізує поняття уроку, пов’язані з operationId.

  • Playwright API testing ↗Microsoft Playwright · перевірено 2026-07-31

    Підтверджує й актуалізує поняття уроку, пов’язані з APIRequestContext.

  • Testomat.io OpenAPI Reference ↗Testomat.io · перевірено 2026-07-31

    Підтверджує й актуалізує поняття уроку, пов’язані з Testomat.io Public API reference.