OpenAPI Schema Object
OpenAPI 3.1 Schema Object описує структуру payload через JSON Schema vocabulary. Список required визначає обов’язкові properties; оголошення property саме по собі не робить його обов’язковим.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Pydantic strict mode
За замовчуванням Pydantic може перетворювати вхідні значення до потрібного типу. Strict mode зменшує coercion і повертає validation error, коли Python input має неправильний тип; правила для JSON input можуть відрізнятися для окремих типів.
Міграція бази даних і тестування даних →JSON structure і межі raw strings
Raw JSON у Java string швидко стає незручним для large/nested payload і parameterization. JSON file у resources є кращим temporary step, але typed object дає compile-time names/types і IDE support. Розбираються objects, arrays, values, nested arrays і відмінності JSON від XML-style wrappers. Модель має повторювати actual wire shape, а не вигадану class hierarchy.
Генерація Java classes з JSON
Для створення DTO з JSON показано кілька варіантів: IntelliJ plugin RoboPOJOGenerator, online generator jsonschema2pojo і ChatGPT. У IntelliJ IDEA Aqua потрібний plugin недоступний, а online generator під час демонстрації не працює, тому невеликий request DTO генерується через ChatGPT. Автор попереджає: LLM може надійно допомогти з малою JSON-структурою, але для великого response може пропусти fields, помилитися з types або вкладеністю. Таку модель потрібно перевіряти проти реального JSON.
OpenAPI, JSON types і шлях даних
Автор розбирає Swagger/OpenAPI descriptions і JSON як мову обміну між clients та backend. Тип, format, required fields, arrays і dates важливі не менше за business value. Окрема тема — перетворення дат і numbers між database, backend і frontend. Якісний test design залежить від розуміння цих transformations; black-box response assertion може не показати, на якому рівні виник defect.
Створення suite через JSON body
Згідно з API-документацією додається `POST` method для створення test suite. Його назва узгоджується з назвою операції в документації, а token, project id і body передаються явно. Для першого варіанта JSON записується в Java text block і передається як request body. Щоб повторні запуски не створювали однакові назви, шаблон форматується через `String.format`, а до title додається current timestamp.
RoboPOJOGenerator і межі AI-generated DTO
У повній IntelliJ IDEA демонструється RoboPOJOGenerator: у нього вставляється реальний JSON, обираються Jackson і Lombok settings, після чого plugin створює повнішу object structure. Цей результат містить поля, які пропустила LLM-generated версія. Для маленьких JSON ChatGPT може бути зручним стартом, але для великих response автор його не радить. На кожному проєкті Jackson потребує одноразового узгодження з реальними JSON conventions. Після цього typed responses дають контрактну перевірку fields і types, а над ними можна будувати reusable assertion classes.
Вебсервіси, SOAP і RESTful
Вебсервіс подається як software component, через який розподілені системи обмінюються даними. SOAP оперує messages і XML contracts, тоді як RESTful services будують інтерфейс навколо resources та HTTP semantics. Автор порівнює XML, JSON, binary payloads і statefulness. Практичний висновок для тестувальника: перед автоматизацією треба визначити реальний protocol, media types і contract, а не припускати REST лише за JSON payload.
Структуровані config-файли й config server
Наступний рівень — JSON, YAML, XML або інший структурований формат, який можна десеріалізувати у типізований config object. Це допомагає групувати налаштування за сервісами й середовищами, але файл із секретами все одно не можна публікувати в Git. У складнішій системі конфігурацію може віддавати централізований config server. Він дозволяє сервісам отримувати актуальні домени, ключі й feature flags, інколи без повного redeploy. Тестовий код не повинен створювати паралельне джерело правди, якщо може безпечно використати той самий контрольований механізм, що й продукт.
POJO generation і Jackson mapping
POJO описує fields, accessors, equality/hash і string representation. Моделі можна згенерувати з real JSON через jsonschema2pojo або RoboPOJOGenerator, обравши Jackson annotations і, за потреби, Lombok. `@JsonProperty` зв’язує JSON name з Java field, Jackson Databind serialization/deserialization перетворює DTO у request body і response назад у object. `null`, missing field, empty object і empty array — різні contract states і потребують окремих tests.
Сирий JSON для requests і typed objects для responses
Якщо request DTO поки занадто складний, request JSON можна тимчасово зберігати у resources і відправляти як file/string. Для response автор наполягає на typed object: так deserialization одразу виявляє зміну structure або field types, яка могла б поламати frontend. Помилки Jackson потрібно читати і звіряти з документацією або пошуком, а не механічно копіювати AI-відповідь. Configuration, helpers і DTO варто рознести за окремими classes, щоб не змішувати mapping, transport і assertions.
Дослідження API, frontend і авторизації
Перед автоматизацією API потрібно дослідити, як із ним працює frontend. Network tab дає фактичні requests навіть тоді, коли документації немає або вона застаріла. На прикладі sign-in показано `POST` зі status `302`, що може свідчити про Backend for Frontend або gateway із власною логікою. Форма відправляє email, password, ознаку remember me і authenticity token. Якщо API не має окремого login endpoint, автотест може завантажити HTML, витягнути токен і відтворити `application/x-www-form-urlencoded` request. У відео натомість використовується задокументований API token/login flow. Автор окремо показує, що payload може бути form data або JSON.