Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Оберіть одну DTO з проєкту.
Для кожного field зафіксуйте source entity/service, mapping rule, nullability, required status, serializer behavior і regression test.
Додайте один gateway header, який має пройти до внутрішнього service.
Mapping table і один перевірений routing contract.
Приклад відсікає coercion id із str у int, відсутній required field і невідомі extra fields.
Valid payload приймається; два invalid payloads спричиняють ValidationError.
Міграція бази даних і тестування даних →Одна 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 не зникне.
На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по `taxId` чи додаткові атрибути. Поля на кшталт `createdAt`, `updatedAt` і `deletedAt` можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.
Для створення DTO з JSON показано кілька варіантів: IntelliJ plugin RoboPOJOGenerator, online generator jsonschema2pojo і ChatGPT. У IntelliJ IDEA Aqua потрібний plugin недоступний, а online generator під час демонстрації не працює, тому невеликий request DTO генерується через ChatGPT. Автор попереджає: LLM може надійно допомогти з малою JSON-структурою, але для великого response може пропусти fields, помилитися з types або вкладеністю. Таку модель потрібно перевіряти проти реального JSON.
З реального 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, і все одно звіряти з контрактом.
Якщо request DTO поки занадто складний, request JSON можна тимчасово зберігати у resources і відправляти як file/string. Для response автор наполягає на typed object: так deserialization одразу виявляє зміну structure або field types, яка могла б поламати frontend. Помилки Jackson потрібно читати і звіряти з документацією або пошуком, а не механічно копіювати AI-відповідь. Configuration, helpers і DTO варто рознести за окремими classes, щоб не змішувати mapping, transport і assertions.
Навіть просте перейменування `surname` на `lastName` зачіпає кілька шарів: database/entity, зовнішній service, mapping і DTO. Якщо API має повертати `fullName`, service може формувати його з `name` та `lastName`; отже, механічне копіювання одного поля дасть синтаксично валідний, але семантично неправильний response. Що більше полів і mapping rules, то вищий ризик пропустити зв’язок або зберегти не те значення. Тести мають перевіряти не лише наявність response, а й коректність значень після всіх перетворень.
Первинні перевірки мають бути видимими в тесті, а не захованими в controller. Тому API method повертає `Response`, а test явно перевіряє status code. Така структура спрощує code review і показує, що саме доводить сценарій. Наступний крок — замінити JSON strings на data transfer objects, щоб мати Java types, autocomplete і зручне оновлення полів. Додаються Java Faker для унікальних test data і Lombok для генерації boilerplate. Для Lombok у IntelliJ IDEA потрібні plugin і ввімкнений annotation processing.
MVC стає корисним словником, коли engineer працює з API та backend contract: model представляє дані, controller/endpoint приймає дію, view або client відображає результат. У тестовому коді DTO може типізувати JSON-відповідь, але не повинен автоматично копіювати кожну внутрішню модель сервісу. Сценарій зручно структурувати як Arrange–Act–Assert: підготувати стан, виконати одну ключову дію, перевірити результат. Повторювані варіанти можна виразити data-driven test, якщо таблиця прикладів не приховує різні бізнес-правила. На співбесідах також можуть питати BDD/Gherkin; важливо пояснити, коли цей формат покращує спільне розуміння, а коли лише дублює код.
Lombok `@Data`, constructors і `@Builder` зменшують boilerplate для generated/request models. Builder допомагає зібрати object з optional/nested fields без довгого constructor. Створення valid default DTO можна винести в small factory/generator. Важливо не сховати за таким helper суттєві дані сценарію: у тесті має бути видно, що саме варіюється.