Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Current Pydantic v2 documentation states that input may be converted to declared types and extra fields are ignored by default. Якщо API-тест має виявляти будь-який schema drift, strict behavior і extra='forbid' треба задати явно.
Не встановлено: точну Pydantic version у відео не названо.
2. API автоматизація одразу правильно, MVC, pydantic →За замовчуванням Pydantic може перетворювати вхідні значення до потрібного типу. Strict mode зменшує coercion і повертає validation error, коли Python input має неправильний тип; правила для JSON input можуть відрізнятися для окремих типів.
Міграція бази даних і тестування даних →Current datamodel-code-generator docs recommend --output-model-type pydantic_v2.BaseModel for new Pydantic v2 projects; backward-compatible default pydantic.BaseModel targets v1. Для code з model_validate() output type треба фіксувати явно.
Не встановлено: версію generator у відео не названо.
2. API автоматизація одразу правильно, MVC, pydantic →Library і CLI utility, що генерує Pydantic-моделі з OpenAPI 3, JSON Schema та інших структурованих sources.
2. API автоматизація одразу правильно, MVC, pydantic →Пояснює alias, validation_alias і serialization_alias для зіставлення JSON з Python fields.
2. API автоматизація одразу правильно, MVC, pydantic → Першоджерело ↗Точний contract model_validate(), ValidationError і model_dump().
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. Згенерований файл — це стартова точка, а не готова доменна модель: автоматичні назви і надто загальні класи ще доведеться уточнювати.
Тест, який перевіряє тільки `200 OK`, пропустить відсутнє поле, `null`, порожній рядок або неправильний mapping. Навіть перевірка переліку полів не гарантує правильного типу чи змісту. Deserialization і schema validation дають дешевий базовий захист: response приводиться до строгої моделі, тому тест одразу виявляє відсутнє поле або неправильний тип. Для цього згадуються інструменти на кшталт Zod у TypeScript і Pydantic у Python. Окремо треба врахувати serializer settings: backend може зовсім вилучати з JSON поля зі значенням `null`.
`PydanticModel.model_validate(response_data["data"])` перетворює dictionary на типізований object і водночас перевіряє schema. Модель suite зводиться до реальних полів на кшталт `id`, `type`, `attributes` і `relationships`, а зайві generated wrappers видаляються. Якщо JSON-ключ не є коректним Python-ідентифікатором, наприклад містить дефіс, для поля задається alias. У коді зберігається `snake_case`, а `Pydantic` зіставляє його з оригінальною назвою в JSON.
Щоб показати цінність 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 у цьому процесі допомагають поступово відтворити фактичний контракт.