Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
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.
Для Jackson2 deserialization явно підключається Jackson Databind. Поля JSON на кшталт `created-at`, які не відповідають Java naming conventions, мають бути явно зв’язані з fields через `@JsonProperty`. Виявляється ще одна контрактна різниця: create endpoint повертає один data object, а list endpoint — array таких objects. Одна й та сама field type не може безпечно представляти обидва shapes, тому моделі розділяються на single response і list response.
У повній 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.
Якщо request DTO поки занадто складний, request JSON можна тимчасово зберігати у resources і відправляти як file/string. Для response автор наполягає на typed object: так deserialization одразу виявляє зміну structure або field types, яка могла б поламати frontend. Помилки Jackson потрібно читати і звіряти з документацією або пошуком, а не механічно копіювати AI-відповідь. Configuration, helpers і DTO варто рознести за окремими classes, щоб не змішувати mapping, transport і assertions.
Одна model для request і response придатна лише тоді, коли wire shapes справді збігаються. Якщо response має generated id/timestamps або request забороняє server-owned fields, потрібні separate `PetRequest` і `PetResponse`. Невдала deserialization найчастіше означає incorrect DTO shape/type або Jackson configuration. Виправлення — звірити модель з real JSON/OpenAPI contract, а не додавати random annotations, доки exception не зникне.
З реального JSON response генерується `SuiteResponse` із nested data, attributes та relationships. RestAssured response переводиться в Java class через `extract().as(...)`. Після цього test отримує autocomplete для `getData()`, attributes, id, type і title замість string paths. Перший запуск виявляє, що response не приводиться до згенерованої моделі автоматично. Відео залишає цей невдалий прохід видимим, щоб показати реальну складність великих DTO і Jackson configuration.
Через зміни в Jackson знадоблюється явна RestAssured configuration з `Jackson2MapperFactory` та налаштованим `ObjectMapper`. Після цього deserialization послідовно виявляє unrecognized fields у неповному DTO. Помилки читаються як карта того, які fields або constructors бракують. Автор показує, як початково можна віддати exception ChatGPT для пояснення, але не приймати відповідь без перевірки. Під час демонстрації згенерована модель пропускає кілька real response fields і змішує object з array. Це підтверджує, що великі DTO потрібно генерувати інструментом, який парсить повний JSON, і все одно звіряти з контрактом.
Generator може створити `assertThat(pet).hasName(...)`, але import conflicts і plugin age можуть звести користь нанівець. Сучасний AssertJ already має rich extracting/recursive/custom assertion APIs, тому generation варта лише для real repeated domain vocabulary. API-first підхід робить specification upstream input для backend і clients. Jackson deserialization вже перевіряє shape/types, але не доводить business semantics. Окрема contract-testing infrastructure потрібна, коли spec/code generation не закривають real producer–consumer risk.