2. API автоматизація одразу правильно, MVC, pydantic

Замість того щоб працювати з response як із набором рядків і dictionary keys, пропонується описати його через Pydantic. Так тест перевіряє не лише наявність значення, а й структуру, типи та обов’язковість полів.

Джерелом схеми може бути OpenAPI-специфікація Testomat.io. Якщо документації немає, модель можна початково згенерувати з реального JSON через JSON-to-Pydantic і потім відредагувати. Автор одразу попереджає: навіть офіційна специфікація може відставати від фактичної response schema.

До проєкту додаються pydantic і datamodel-code-generator. Генератор приймає локальну схему або URL, обирає Pydantic BaseModel як output і зберігає Python-моделі у src/api/models.

Довгу CLI-команду краще винести в project configuration: там фіксуються input, output, версія Python і правила aliases. Згенерований файл — це стартова точка, а не готова доменна модель: автоматичні назви і надто загальні класи ще доведеться уточнювати.

Показано спрощене застосування Model–View–Controller. Model описує DTO і response data; Controller інкапсулює запити; роль view у цьому тестовому контексті не розвивається.

Кожен REST resource — projects, suites, runs, templates, tests, users — отримує власний controller з потрібними операціями create, get, update, delete. Це тримає тестовий сценарій на рівні предметних дій, а URL, headers і розбір response залишаються в одному місці.

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.

pytest fixtures виконують login, отримують JWT і передають його до ProjectController чи SuiteController. Якщо token вже збережено у scope fixture, нова авторизація не потрібна.

Для створення suite спершу потрібен target project. Його можна підготувати окремою fixture або отримати в самому тесті через ProjectController.get_all(). Вибір залежить від того, чи це спільний precondition, чи важливий крок конкретного сценарію.

SuiteController.create() приймає project_id, title і description, формує payload та викликає post базового controller. Потрібні поля звіряються не лише з документацією, а й з request у browser DevTools. У демо офіційна схема містить сумнівну вимогу до suite_id до створення suite, тож real request і response виступають важливою перевіркою контракту.

Відповідь Testomat.io загортає основну сутність у поле data. Після response.json() тест бере response_data["data"] і валідує саме цю вкладену структуру.

PydanticModel.model_validate(response_data["data"]) перетворює dictionary на типізований object і водночас перевіряє schema. Модель suite зводиться до реальних полів на кшталт id, type, attributes і relationships, а зайві generated wrappers видаляються.

Якщо JSON-ключ не є коректним Python-ідентифікатором, наприклад містить дефіс, для поля задається alias. У коді зберігається snake_case, а Pydantic зіставляє його з оригінальною назвою в JSON.

from pydantic import BaseModel, ConfigDict, Field

class SuiteAttributes(BaseModel):
    model_config = ConfigDict(extra="ignore")
    file_type: str = Field(alias="file-type")
    code: str | None = None

payload = {"file-type": "manual", "code": None, "ignored": "value"}
attributes = SuiteAttributes.model_validate(payload)
assert attributes.file_type == "manual"
assert attributes.code is None
print(attributes.model_dump())

Згенерована models.py містить багато загальних класів на кшталт Attributes1, Attributes2, тому його краще використовувати як reference і поступово називати моделі за їхньою предметною роллю.

Під час демо тест падає через неправильні imports і видалену fixture. Для circular import корисно читати останній змістовний фрейм traceback: там зазвичай вказано реальний модуль і напрям залежності. Якщо pytest не знаходить fixture, він друкує перелік усіх доступних fixtures, що допомагає помітити назву або проблему з discovery.

Щоб показати цінність schema validation, тип одного поля навмисно змінюється на str. Pydantic одразу повідомляє шлях до поля, очікуваний тип і фактичне None.

Якщо None справді дозволено контрактом, тип має це відображати, наприклад str | None. Any варто залишати лише для поля, структура якого справді нестабільна або не важлива для поточної перевірки.

Домашнє завдання — створити suite у вибраному project, отримати його через API і перевірити результат. Потім той самий підхід застосовується до test case: потрібно реалізувати TestController, request model, response model і перевірку створеної сутності.

Базові HTTP-методи, headers, error handling і logging перевикористовуються з BaseController. Якщо documentation schema неповна, спершу виконується реальний request, а його JSON response перетворюється на початкову Pydantic-модель. Помилки validation у цьому процесі допомагають поступово відтворити фактичний контракт.