# Архитектура современных Java-приложений: полный цикл разработки на Spring Источник: https://www.youtube.com/watch?v=31KTdfRH6nY Канал: freeCodeCamp.org Опубликовано: 18.03.2024 --- «Используйте те инструменты, которые позволяют вам достичь продуктивности, будь то хоть блокнот или терминал с Vim», — призывает Дэн Вега, напоминая, что за технологическим шумом современного Spring Boot 3 важно не потерять суть разработки. Этот интенсивный гайд превращает хаос конфигураций в стройную архитектуру, проходя путь от простой инициализации проекта до создания масштабируемых REST API, интегрированных с Docker и PostgreSQL. ## 🚀 Введение в разработку на Spring Boot 3 [[JUMP:00:27]] Этот курс представляет собой практическое руководство по созданию современных веб-приложений на Java с использованием фреймворка Spring Boot 3. Основная задача обучения — пройти путь от настройки окружения до реализации полноценного REST API, взаимодействующего с базой данных, и обеспечения качества кода через комплексное тестирование. Автор курса, Дэн Вега (Dan Vega), Spring Developer Advocate в Broadcom и Java Champion, подчеркивает, что цель программы — дать необходимые навыки для самостоятельной разработки приложений, которые слушатели смогут применить в своих собственных проектах, будь то трекеры тренировок, кулинарные рецепты или любые другие идеи. ### Необходимый стек технологий и инструменты [[JUMP:00:27]] Для эффективного прохождения курса и дальнейшей работы с экосистемой Spring разработчику потребуется определенный набор инструментов. Основой является язык Java: для Spring Boot 3 необходимо наличие JDK 17 или выше (рекомендуется использование актуальных версий, таких как 21). Для управления версиями Java на macOS крайне полезен инструмент SDKMAN!, позволяющий параллельно устанавливать и переключаться между различными SDK. Ключевые элементы рабочего окружения: * **Система сборки:** Maven или Gradle для управления зависимостями и плагинами сборки. * **IDE:** Дэн Вега предпочитает IntelliJ IDEA Ultimate Edition за её продуктивность, однако подчеркивает: использовать можно любой редактор, в котором разработчик чувствует себя максимально комфортно, включая Community-версию IDEA, VS Code или Spring Tool Suite. * **Тестирование API:** Для проверки работы REST-интерфейсов подойдут Postman, утилита cURL, HTTPie или встроенный HTTP-клиент IntelliJ IDEA. * **Контейнеризация:** Использование Docker и Docker Compose будет рассмотрено позже при настройке полноценной базы данных. ### Экосистема Spring и начало работы с Initializer [[JUMP:11:39]] Spring — это обширный и гибкий фреймворк, охватывающий практически все аспекты разработки современного ПО: от микросервисов и реактивных веб-приложений до серверных функций, пакетной обработки данных и даже CLI-приложений. Популярность фреймворка обусловлена его надежностью, постоянной поддержкой со стороны крупной инженерной команды и бесшовной интеграцией различных модулей (например, Spring Cloud для распределенных систем). При возникновении вопросов первым источником истины всегда должна быть официальная документация на [spring.io](https://spring.io), которая обновляется чаще, чем сторонние статьи. Процесс создания проекта начинается с использования [Spring Initializer (start.spring.io)](https://start.spring.io). Этот сервис позволяет: 1. Выбрать систему сборки (Maven/Gradle) и язык (Java, Kotlin, Groovy). 2. Указать версию Spring Boot (актуальная на момент записи — 3.2.3). 3. Задать параметры проекта (Group, Artifact). 4. Добавить начальные зависимости, такие как `Spring Web` (для построения API) и `Spring Boot DevTools` (для ускорения разработки). После генерации проекта и его открытия в IDE, разработчик получает стандартную структуру Maven-проекта с разделением на исходный код (`src/main/java`) и ресурсы (`src/main/resources`), готовую к написанию первого функционала. ## 🛠️ Анатомия Spring Boot: от структуры проекта до инверсии управления и Java Records [[JUMP:25:13]] ### Структура проекта, Maven Wrapper и магия Dev Tools [[JUMP:25:13]] Разбор устройства типичного приложения на Spring Boot начинается с его файловой структуры. Внутри проекта четко разделены директории для основного кода и ресурсов (`src/main`) и тестовых классов (`src/test`), которые зеркально повторяют структуру пакетов приложения. Важным элементом современной экосистемы является утилита Maven Wrapper (`mvnw`). Её наличие гарантирует, что разработчику не нужно вручную устанавливать Maven на локальную машину: встроенная обертка автоматически скачает всё необходимое для сборки. Это значительно упрощает совместную работу, когда проект передается между членами команды. Сердцем сборки выступает файл `pom.xml`, где декларируются все зависимости. Дэн Вега обращает внимание на концепцию Spring Boot Starters — специальных стартовых наборов, которые агрегируют в себе множество подзависимостей, избавляя программиста от рутины по их поиску и ручной настройке. Запуск приложения возможен как из среды разработки (IDE) кнопкой «Play», так и через терминал с помощью команды `./mvnw spring-boot:run`. Процесс разработки не всегда проходит гладко: Дэн демонстрирует типичную ошибку конфликта сетевых портов и оперативно решает её через встроенную утилиту JPS, завершая зависший процесс по его идентификатору. Из коробки в Spring Boot уже настроено логирование на базе библиотеки SLF4J. Разработчику достаточно объявить логгер через фабрику, чтобы выводить кастомные сообщения с различными уровнями (INFO, DEBUG, WARN). Дополнительное удобство при локальной разработке предоставляет модуль Spring Boot Dev Tools. Он обеспечивает две важнейшие функции: * Автоматический перезапуск приложения (Application Restart) при сохранении изменений в коде, если в настройках компилятора IDE активирована опция автоматической сборки проекта. * Установку разумных дефолтных настроек для окружения разработчика — например, автоматическое включение веб-консоли для встроенной базы данных H2, избавляя от необходимости прописывать это в конфигурации вручную. ### Инверсия управления: почему стоит забыть про ключевое слово new [[JUMP:31:58]] Переходя к написанию бизнес-логики, Дэн затрагивает фундаментальную концепцию Spring — инверсию управления (Inversion of Control, IoC). Чтобы наглядно продемонстрировать её суть, он создает простой класс `WelcomeMessage` в произвольном пакете `foo.bar`. Если инстанцировать этот класс вручную, используя классическое Java-выражение `var welcomeMessage = new WelcomeMessage()`, программа успешно отработает, но управление жизненным циклом объекта останется на стороне разработчика. В масштабных корпоративных приложениях такой подход быстро превращается в неуправляемый хаос. «Каждый раз, когда вы видите ключевое слово `new`, скорее всего, в контексте Spring вы делаете что-то не так», — напоминает Дэн. Идея IoC заключается в том, чтобы полностью передать обязанность по созданию, конфигурации и связыванию объектов самому фреймворку. Все управляемые объекты живут внутри огромного контейнера, который называется Application Context. В терминологии Spring такой управляемый объект называется бином (Bean). Бин — это обычный экземпляр класса, вокруг которого фреймворк выстраивает дополнительную метаинформацию для управления его жизненным циклом. Однако попытка Дэна запросить бин `WelcomeMessage` напрямую из контекста поначалу оборачивается ошибкой. Причина кроется в правилах сканирования компонентов: класс был создан за пределами основного пакета приложения. Как только Дэн переносит `WelcomeMessage` внутрь базового пакета (`dev.danvega`), механизм Component Scanning автоматически обнаруживает класс, превращает его в Bean, и инверсия управления начинает работать безупречно. ### Проектирование фичи и современная модель данных на Java Records [[JUMP:41:24]] В качестве практического примера Дэн предлагает разработать приложение для трекинга физической активности и бега. Процесс создания новой фичи обнажает важный вопрос архитектуры: как именно структурировать пакеты в проекте? Существует два основных подхода: * Package by Layer (упаковка по слоям): когда создаются отдельные пакеты для контроллеров, моделей, сервисов и репозиториев. Главный минус в том, что для взаимодействия между слоями приходится делать классы публичными. * Package by Feature (упаковка по фичам): когда абсолютно все классы, относящиеся к конкретной доменной области (например, к сущности «Run»), собираются в одном пакете. Дэн отдает предпочтение подходу Package by Feature, поскольку он позволяет использовать область видимости package-private, благодаря чему компоненты внутри пакета могут свободно общаться друг с другом, оставаясь скрытыми от остального приложения. Моделируя сущность `Run` (забег), лектор сначала демонстрирует старый «многословный» способ Java: объявление приватных полей (ID, название, время старта и окончания, мили), создание гигантского конструктора, геттеров, сеттеров, методов `equals()`, `hashCode()` и `toString()`. Это генерирует около 100 строк шаблонного кода (boilerplate). Современная Java позволяет кардинально решить эту проблему с помощью записей (Java Records). Заменив класс на `record Run`, Дэн сокращает объем кода до 12 легко читаемых строк. Записи по своей природе неизменяемы (immutable): у них нет сеттеров, а значения полей можно задать только при создании экземпляра. При этом компилятор автоматически генерирует конструктор со всеми аргументами, методы сравнения и строковое представление. В дополнение к модели создается перечисление `Location` с фиксированными значениями `INDOOR` и `OUTDOOR` для указания типа тренировки. Чтобы мгновенно протестировать модель, Дэн использует интерфейс `CommandLineRunner`, код которого автоматически выполняется сразу после инициализации контекста приложения, успешно выводя созданный объект забега в консоль. В самом конце этого этапа Дэн отмечает, что встроенный сервер Tomcat успешно запустился на порту 8080, что подводит нас к теме веб-приложений и Spring MVC, которая будет подробно разобрана в следующей главе. ## 🌐 Создание REST API и архитектура Spring MVC [[JUMP:50:07]] Приложение на Spring Boot требует настройки точек входа (endpoints), через которые оно будет взаимодействовать с внешним миром. Для этой цели в экосистеме Spring используется паттерн MVC (Model-View-Controller). Модель (Model) в нашем случае — это доменная сущность, данные, с которыми мы работаем. Ранее в разговоре они касались структуры проекта и разработки модели данных. Представление (View) при создании REST API — это не привычная HTML-страница, а данные в формате JSON, которые возвращаются пользователю. Центральным элементом системы является контроллер (Controller) — своего рода «регулировщик» трафика. Его задача максимально проста: принять HTTP-запрос, при необходимости делегировать обработку бизнес-логики другим классам (сервисам или репозиториям) и вернуть ответ. Контроллеры не должны заниматься управлением данными напрямую — они лишь связующее звено. ### 🛠 Аннотации и маппинг запросов [[JUMP:51:51]] В Java-разработке на Spring широко используются аннотации. Они позволяют добавлять поведение классам или методам, значительно сокращая объем шаблонного кода. Для создания контроллера мы используем аннотацию `@RestController`. Она сообщает Spring, что данный класс является REST-контроллером и по умолчанию должен возвращать тело ответа в формате JSON. Чтобы связать метод контроллера с конкретным URL, применяются аннотации маппинга: * `@RequestMapping`: позволяет задать путь и HTTP-метод. * `@GetMapping`, `@PostMapping`, `@PutMapping`, `@DeleteMapping`: специализированные варианты для каждого типа HTTP-запросов, которые предпочтительнее в использовании. Например, добавление `@GetMapping("/hello")` над методом позволяет приложению отвечать на GET-запрос по адресу `/hello`, возвращая строковое значение. ### 💾 Реализация CRUD-операций и инверсия управления [[JUMP:54:03]] Для реализации полноценного CRUD (Create, Read, Update, Delete) API мы переносим логику хранения данных в отдельный класс — `RunRepository`. Это позволяет отделить управление данными от обработки запросов. Временно мы используем хранилище в оперативной памяти (в виде `ArrayList`), которое инициализируется при запуске приложения с помощью метода, помеченного аннотацией `@PostConstruct`. Основополагающим принципом здесь является инверсия управления (IoC). Мы не создаем экземпляры репозитория через ключевое слово `new` внутри контроллера. Вместо этого мы используем **Dependency Injection** (внедрение зависимостей): контроллер запрашивает экземпляр `RunRepository` через конструктор, а Spring автоматически предоставляет уже готовый объект, которым он управляет. ### 🚀 Динамические пути и работа с телом запроса [[JUMP:1:06:11]] Чтобы сделать API гибким, мы используем динамические переменные в путях. Аннотация `@PathVariable` позволяет извлечь идентификатор из URL и передать его в метод контроллера. При работе с поиском конкретной записи, вместо того чтобы просто возвращать объект, который может быть `null`, мы используем `Optional. Это позволяет элегантно обрабатывать отсутствие данных: например, если запись не найдена, мы выбрасываем `ResponseStatusException` с кодом 404 (Not Found), что является стандартом для корректного API. Для создания новых записей через HTTP POST-запросы мы используем аннотацию `@RequestBody`. Она указывает Spring, что данные, приходящие в теле запроса (в формате JSON), должны быть автоматически десериализованы в соответствующий Java-объект. Для тестирования подобных запросов, которые нельзя выполнить напрямую через браузер, рекомендуется использовать инструменты типа Postman или встроенные HTTP-клиенты в IDE, например, специализированные `.http` файлы в IntelliJ IDEA. ## 🚀 Улучшение API: Валидация и переход к базам данных [[JUMP:1:23:36]] На этапе зрелости REST API недостаточно просто принимать любые входящие данные — критически важно обеспечить контроль их корректности. Ранее в разговоре мы уже реализовали базовые CRUD-операции, но сейчас пришло время усилить надежность системы. ### Валидация данных с помощью Bean Validation API [[JUMP:1:23:36]] Для предотвращения попадания некорректных данных в систему в Spring Boot используется Bean Validation API. Этот подход позволяет декларативно задавать ограничения для полей наших моделей. Первым делом необходимо добавить зависимость `spring-boot-starter-validation` в файл `pom.xml`. После обновления зависимостей в IDE мы можем использовать стандартные аннотации над полями класса или записи (record): * `@NotEmpty`: гарантирует, что строковое поле (например, `title`) не будет пустым. * `@Positive`: предотвращает ввод отрицательных чисел для полей вроде `miles`. * Дополнительные ограничения включают `@Future`, `@Past`, `@Min`, `@Max` и другие, обеспечивающие гибкую настройку правил. Чтобы активировать эти правила в контроллере, достаточно добавить аннотацию `@Valid` перед аргументом метода, принимающего данные. Если переданный объект нарушает правила, Spring автоматически прервет выполнение метода и вернет клиенту ошибку `400 Bad Request`, избавив нас от написания ручных проверок. При наличии `spring-boot-devtools` подробности ошибок валидации будут автоматически логироваться в консоль, что значительно упрощает отладку. --- ### Подключение базы данных H2 и JDBC Client [[JUMP:1:33:20]] До этого момента мы использовали in-memory представление данных, которое обнулялось при каждом перезапуске приложения. Теперь мы переходим к интеграции с полноценной базой данных. Для быстрого старта идеально подходит H2 — встраиваемая база данных, работающая прямо в оперативной памяти. Процесс интеграции включает следующие шаги: 1. **Добавление зависимостей:** Необходимо подключить `h2` (runtime-зависимость) и `spring-boot-starter-jdbc` для работы с JDBC API. 2. **Настройка подключения:** Spring автоматически настраивает соединение. Благодаря `DevTools`, мы получаем доступ к H2 Console — веб-интерфейсу, позволяющему визуально управлять содержимым базы данных через браузер. 3. **Именование БД:** Мы можем управлять именем базы данных через `application.properties`, установив `spring.datasource.name=Runners`, что позволяет получить предсказуемый JDBC URL для подключения. ### Автоматизация схемы через schema.sql [[JUMP:1:39:35]] Поскольку in-memory база данных очищается при каждом запуске, Spring предоставляет механизм автоматической инициализации схемы. Достаточно создать файл `schema.sql` в директории `src/main/resources`. При старте приложения Spring обнаружит этот файл и выполнит содержащиеся в нем SQL-инструкции для создания таблиц, соответствующих нашей модели данных. Это гарантирует, что структура БД всегда будет синхронизирована с кодом приложения. ## 🛠️ Переход к базам данных: Эра JdbcClient и автоматизация данных [[JUMP:1:40:27]] ### От JdbcTemplate к современному JdbcClient [[JUMP:1:42:05]] Долгое время разработчики в экосистеме Spring использовали `JdbcTemplate` для упрощения взаимодействия с базами данных поверх стандартного JDBC API. Однако с выходом Spring Boot 3.2 ситуация качественно изменилась: появился `JdbcClient`. Этот инструмент предлагает разработчикам интуитивный беглый (fluent) API, который делает код работы с базами данных более читаемым и лаконичным, сохраняя при этом гибкость нативных SQL-запросов. Интеграция `JdbcClient` в существующий репозиторий `RunRepository` наглядно демонстрирует мощь механизмов внедрения зависимостей (Dependency Injection) в Spring. Благодаря наличию JDBC API в classpath, Spring Boot автоматически конфигурирует экземпляр `JdbcClient` и помещает его в контекст приложения. Разработчику остаётся лишь получить его через инжекцию в конструктор, избегая ручного создания объектов. Первым шагом в замене старого хранилища в оперативной памяти становится написание метода `findAll()`. С использованием `JdbcClient` этот процесс выглядит как лаконичная цепочка вызовов: определение SQL-скрипта `SELECT * FROM run`, выполнение запроса и автоматический маппинг результатов в Java-рекорды. ### Полноценный CRUD на уровне базы данных [[JUMP:1:47:15]] Для полноценной замены коллекции в оперативной памяти реальной базой данных требуется реализовать весь спектр CRUD-операций. При поиске сущности по идентификатору через метод `findById` используется механизм именованных параметров. `JdbcClient` позволяет гибко связывать переменные из сигнатуры метода с SQL-запросом, возвращая безопасный контейнер `Optional` на случай, если запись отсутствует в таблице. Что касается модификации данных — создания, обновления и удаления записей — все эти операции выполняются через метод `update()` в `JdbcClient`. Важной архитектурной деталью здесь является контроль целостности данных: метод возвращает количество изменённых строк. Это позволяет приложению программно удостовериться, что в результате транзакции пострадала ровно одна ожидаемая запись, и выдать ошибку, если это не так. Проверка работоспособности обновлённого контроллера через встроенную консоль H2 подтверждает, что слой абстракции работает прозрачно. ### Программный бутстрап и пакетная загрузка через JSON [[JUMP:1:50:38]] Использование статичных файлов инициализации вроде `data.sql` удобно на старте, но реальные задачи часто требуют программного управления процессом первичной загрузки данных (bootstrap). Идеальным инструментом для этого выступает `CommandLineRunner` — функциональный интерфейс Spring, метод `run` которого автоматически выполняется сразу после полного запуска контекста приложения. Поскольку это функциональный интерфейс, в простых сценариях его можно объявить в виде Lambda-выражения прямо внутри конфигурационного бина. Однако для комплексных задач инициализации эффективнее выносить логику в отдельные компоненты. Пример тому — класс `RunJsonDataLoader`, помеченный аннотацией `@Component`. Его задача — прочитать пакет из 10 готовых пробежек из файла `runs.json`, десериализовать их с помощью встроенного `ObjectMapper` в промежуточный Java-рекорд и массово сохранить в базу данных. Такой подход снабжён проверкой: загрузка происходит только в том случае, если текущий счётчик записей в таблице равен нулю. ### Подготовка к продакшен-стеку: Прощай, H2 [[JUMP:2:00:09]] Встроенная база данных H2 великолепно подходит для быстрой итерации и локальных тестов, но реальный продакшен требует промышленного решения. В качестве такого стандарта выступает СУБД PostgreSQL. С точки зрения написанного Java-кода переход на новую базу практически незаметен, что доказывает зрелость абстракций Spring. Основные изменения затрагивают конфигурацию окружения: необходимо переопределить URL подключения, имя пользователя и пароль. Стоит учитывать нюанс: по умолчанию Spring Boot автоматически выполняет инициализирующий скрипт `schema.sql` только для встроенных баз данных (таких как H2). При переходе на внешнюю СУБД этот запуск необходимо форсировать, установив свойство `spring.sql.init.mode` в положение `always`. Чтобы избавить разработчика от необходимости вручную скачивать и настраивать PostgreSQL в операционной системе, применяется контейнеризация через Docker. Начиная со Spring Boot 3.1, в экосистему был добавлен модуль поддержки Docker Compose, который радикально упрощает локальную разработку. Для перехода на полноценный стек в проекте выполняются следующие шаги: * Удаление из файла `pom.xml` зависимости встроенной базы данных H2 и добавление драйвера `postgresql` вместе с модулем поддержки Docker Compose. * Создание в корневой директории файла конфигурации `compose.yaml`, автоматически описывающего параметры контейнера базы данных на основе выбранных зависимостей. * Настройка параметров подключения к PostgreSQL (URL, логин, пароль) внутри файла свойств приложения. ## 🐳 Управление данными с PostgreSQL и Docker [[JUMP:2:05:33]] Переход на использование PostgreSQL в связке с Docker Compose позволяет стандартизировать среду разработки для всей команды. Вместо того чтобы полагаться на случайные параметры контейнера, разработчики могут явно задать версию образа PostgreSQL в конфигурационном файле, обеспечивая единообразие инфраструктуры. При настройке `docker-compose.yml` важно корректно определить сопоставление портов. Если указать только порт контейнера (5432), Docker выделит динамический порт на локальной машине, что затруднит подключение внешних инструментов. Явное указание маппинга «5432:5432» позволяет стабильно подключаться к базе данных через привычные инструменты управления, такие как база данных в IntelliJ IDEA, используя `localhost:5432`. Spring Boot существенно упрощает работу с конфигурациями через механизм `ConnectionDetails`. Разработчикам не нужно дублировать параметры подключения (имя пользователя, пароль, URL базы данных) в файле `application.properties`, если они уже описаны в Docker Compose. Среда выполнения автоматически считывает эти детали и внедряет их в соответствующие свойства, что делает инфраструктуру проекта чище и избавляет от избыточного кода. ### 🛠 Spring Data JDBC: автоматизация и гибкость [[JUMP:2:10:02]] После перехода с базовых решений (ранее в разговоре упоминались JDBC-клиент и H2), проект переходит к использованию Spring Data JDBC. Этот проект в составе экосистемы Spring Data предоставляет мощные абстракции, позволяя минимизировать рутинную работу с CRUD-операциями. Ключевые преимущества Spring Data JDBC: * **Автоматизация CRUD**: Вместо написания SQL-запросов вручную для базовых операций, достаточно создать интерфейс, расширяющий `ListCrudRepository`. Spring Data самостоятельно сгенерирует реализацию во время выполнения. * **Динамическая генерация запросов**: Вы можете создавать кастомные методы прямо в интерфейсе репозитория, используя правила именования, например `findByLocation`. Spring автоматически преобразует такие сигнатуры в SQL-запросы. * **Моделирование предметной области**: В отличие от более тяжеловесных решений вроде Spring Data JPA, использующих hibernate и сложный ORM, JDBC-вариант работает ближе к «чистому» SQL, что упрощает понимание того, как именно данные маппятся на объекты домена. Для начала работы достаточно добавить зависимость `spring-boot-starter-data-jdbc` в `pom.xml`. Затем, пометив поле идентификатора сущности аннотацией `@Id` и, при необходимости, добавив поле версии (аннотация `@Version`) для отслеживания состояния строк, разработчик получает полноценную систему работы с данными без написания шаблонного кода. В случаях, когда стандартных возможностей недостаточно, всегда можно прибегнуть к аннотации `@Query` для написания собственных SQL-выражений, сохраняя при этом все преимущества репозиторного подхода. ## 🌐 Взаимодействие с внешними сервисами: Rest Client и HTTP-интерфейсы [[JUMP:2:30:37]] Современные приложения на базе Spring Boot 3 всё чаще требуют интеграции с внешними микросервисами. Для реализации такого взаимодействия в экосистеме Spring произошла эволюция инструментов, направленная на упрощение кода и отказ от избыточного boilerplate. ### Использование Rest Client [[JUMP:2:31:37]] Одним из наиболее эффективных инструментов для синхронного общения между микросервисами является `RestClient`, представленный в Spring Framework 6.1 (и включенный в Spring Boot 3.2). По своей сути это интерфейс, предлагающий современный, плавный (fluent) API, который значительно выигрывает по читаемости у классического `RestTemplate`. Основные аспекты работы с `RestClient`: * **Инициализация:** Поскольку `RestClient` является интерфейсом, для его создания используются статические фабричные методы или `RestClient.Builder`. В Spring Boot 3 приложение автоматически управляет экземпляром `RestClient.Builder`, что упрощает внедрение зависимостей. * **Гибкость:** `RestClient` не привязан к конкретному низкоуровневому HTTP-клиенту. С помощью `RequestFactory` разработчик может легко переключаться между реализациями (например, стандартным JDK HTTP-клиентом, Jetty или Apache HttpClient), просто передав нужную фабрику в билдер. * **Кастомизация:** Инструмент позволяет легко настраивать поведение запросов: устанавливать заголовки по умолчанию, задавать таймауты соединения или чтения, а также использовать интерцепторы (`ClientHttpRequestInterceptor`) для решения задач вроде аутентификации (например, добавление JWT-токена) или автоматического повтора запросов при сбоях. * **Выполнение запросов:** В отличие от `RestTemplate` с его множеством перегруженных методов, API `RestClient` интуитивно понятно разделяет методы на `get()`, `post()`, `put()`, `delete()` и так далее, предлагая выбор между простым методом `retrieve()` или более детальным `exchange()` для полного контроля над ответом. ### HTTP-интерфейсы в Spring [[JUMP:2:41:03]] Вершиной абстракции для вызова внешних сервисов в Spring являются HTTP-интерфейсы. Этот подход позволяет полностью отказаться от написания кода самого HTTP-клиента, превращая процесс вызова внешнего API в работу с обычным Java-интерфейсом. * **Декларативный подход:** Вместо ручного формирования запросов, разработчик описывает контракт взаимодействия через аннотации. Например, метод помечается как `@GetExchange`, где в параметрах указывается URI, по которому будет отправлен запрос. * **Прокси-фабрики:** С помощью `HttpServiceProxyFactory` Spring в рантайме генерирует реализацию интерфейса, основываясь на предоставленном `RestClient`. Это превращает вызов внешнего сервиса в вызов обычного Java-метода, что делает код чище и проще для поддержки. * **Автоматизация:** Использование таких интерфейсов позволяет сосредоточиться на бизнес-логике, а не на технической реализации сетевых вызовов. Как отмечалось ранее в обсуждении репозиториев (Spring Data), это еще один пример того, как фреймворк берет на себя рутинную работу по созданию реализаций компонентов на основе простых контрактов. Этот подход идеально вписывается в современный MVC-стек, обеспечивая прозрачную и легко тестируемую интеграцию между компонентами распределенной системы. ## 🧪 Экосистема тестирования в Spring Boot: от изолированных unit-тестов до срезов контекста [[JUMP:2:55:38]] ### Настоящие unit-тесты: проверка бизнес-логики без участия Spring [[JUMP:2:56:19]] Когда речь заходит о тестировании компонентов, не зависящих от внешней инфраструктуры, вовлекать полноценный фреймворк Spring нет необходимости. В качестве примера рассматривается класс `InMemoryRunRepository`, который хранит состояние внутри обычной коллекции в оперативной памяти. Для создания теста используется встроенный функционал среды разработки IntelliJ IDEA, которая автоматически генерирует правильную структуру пакетов и имя класса. Фреймворк JUnit 5 по умолчанию ищет тестовые классы, названия которых заканчиваются на `Test` или `Tests`. Такой тест является «чистым» unit-тестом, поскольку в нем отсутствуют какие-либо аннотации Spring. Для инициализации тестовой среды применяется метод с аннотацией `@BeforeEach`, выполняющий предварительную настройку окружения перед каждым тестовым запуском. Поскольку Spring не управляет жизненным циклом компонента в таком сценарии, методы жизненного цикла (такие как `@PostConstruct`) не вызываются автоматически, и тестовые данные приходится добавлять в коллекцию вручную. Типичный тест, например `shouldFindAllRuns`, вызывает метод репозитория и проверяет результат с помощью утверждений (assertions). В JUnit 5 хорошей практикой является передача третьего необязательного аргумента в метод утверждения — текстового сообщения, которое выводится в случае падения теста (например, «should have returned 2 runs»). Спикер также упоминает подход TDD (Test-Driven Development), при котором разработчик сначала пишет падающий тест, а затем реализует код метода для его успешного прохождения. Набор простых тестов позволяет быстро покрыть всю базовую функциональность компонента, включая поиск по валидному или невалидному ID и создание новых записей. ### Тестирование срезов данных: эффективное использование аннотации @JdbcTest [[JUMP:3:02:01]] Переходя к тестированию компонентов, работающих с базой данных, таких как `JdbcRunRepository`, подход меняется. Здесь уже нельзя обойтись простым unit-тестом, так как коду требуется инфраструктура Spring. Использование универсальной аннотации `@SpringBootTest` на начальном этапе кажется удобным, однако по мере роста приложения это существенно замедляет сборку, поскольку аннотация полностью загружает весь контекст приложения со всеми классами системы. Для оптимизации процесса в Spring Boot существуют так называемые «тесты срезов» (Slice Tests), загружающие только необходимую часть контекста. Для слоя доступа к данным используется аннотация `@JdbcTest`. Согласно официальной документации, `@JdbcTest` обладает следующими особенностями: * Отключает полную автоконфигурацию приложения, оставляя только конфигурацию, релевантную для JDBC-компонентов. * По умолчанию является транзакционной и автоматически откатывает любые изменения в базе данных в конце каждого тестового метода. * Предоставляет встроенную базу данных в оперативной памяти, заменяя ею параметры реального источника данных. Ранее в разговоре авторы касались интеграции PostgreSQL через Docker и использования базы данных H2, однако для локальных тестов спикер предпочитает подход с Testcontainers, чтобы окружение было максимально приближено к продакшену. Если разработчик хочет отказаться от автоматической подмены базы данных на встраиваемую и использовать уже запущенную внешнюю БД, применяется аннотация `@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)`. При написании таких тестов внедрение зависимостей через поле с помощью `@Autowired` считается допустимым, поскольку разработчик не тестирует сам тестовый класс. Если нужный бин не подтягивается автоматически из-за специфики работы среза, его необходимо импортировать явно с помощью аннотации `@Import`. ### Изолированная проверка веб-слоя с помощью @WebMvcTest и MockMvc [[JUMP:3:09:54]] Следующим важным этапом является тестирование веб-компонентов, а именно контроллера `RunController`. Разработчик может протестировать его с двух ракурсов: как изолированный юнит-тест ввода-вывода веб-слоя и как полноценный интеграционный сценарий. Для изолированного тестирования применяется специализированный срез `@WebMvcTest(RunController.class)`. Эта аннотация автоматически настраивает инструмент `MockMvc`, который является главной точкой входа для поддержки серверного тестирования Spring MVC. С помощью `MockMvc` можно имитировать HTTP-запросы в изолированном окружении, отправляя, например, GET-запросы на эндпоинт `/api/runs` и проверяя возвращаемый статус ответа. Также в контекст внедряется компонент `ObjectMapper` из библиотеки Jackson, необходимый для сериализации и десериализации JSON-данных. Поскольку контроллер зависит от репозитория, выполняющего запросы к базе данных, в изолированном тесте эту внешнюю зависимость необходимо подменить. Для этого используется аннотация `@MockBean` из фреймворка Mockito, создающая фиктивный объект вместо реального бина. Описание поведения заглушки задается с помощью конструкции `when(...).thenReturn(...)`. Для верификации структуры и содержимого JSON-ответа применяется библиотека `JsonPath`, которая позволяет строить декларативные выражения и проверять, к примеру, размер возвращаемого массива данных. В ходе написания тестов для методов получения, создания и удаления данных разработчик верифицирует корректность HTTP-статусов и точность возвращаемой информации. ### Переход к сквозному тестированию: конфигурация интеграционной среды [[JUMP:3:18:29]] Когда возникает необходимость проверить работу всей цепочки приложения целиком — от контроллера через репозиторий до реальной базы данных, — разработчики переходят к написанию интеграционных тестов. Для этого создается класс `RunControllerIntTest`, разворачивающий полноценный контекст приложения с помощью аннотации `@SpringBootTest`. Чтобы избежать конфликтов портов в тестовом окружении, свойство `webEnvironment` настраивается на использование случайного порта: `@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)`. Для получения динамически назначенного номера порта внутри тестового класса используется аннотация `@LocalServerPort`, которая внедряет значение в целочисленную переменную. Ранее в разговоре упоминалось использование Rest Client для выполнения HTTP-запросов. В методе предварительной настройки интеграционного теста `@BeforeEach` создается экземпляр `RestClient` с базовым URL, указывающим на локальный хост и динамический порт (`http://localhost:` + port). Это позволяет выполнять настоящие сетевые вызовы к развернутому тестовому веб-серверу для проверки сквозных сценариев работы приложения. ## 🏁 Проверка приложения в бою: сквозное интеграционное тестирование и финал курса [[JUMP:200:51]] ### Сквозная проверка взаимодействия: от контроллера до базы данных [[JUMP:200:51]] Финальный этап разработки любого серьезного веб-приложения неизбежно упирается в проверку того, как все спроектированные компоненты работают в связке. Автор переходит к демонстрации полноценного интеграционного теста, который призван подтвердить корректность всей цепочки вызовов внутри приложения на Spring Boot 3. В рамках этого теста выполняется реальный HTTP-запрос к эндпоинту контроллера, который перенаправляет вызов в репозиторий, а тот, в свою очередь, обращается к базе данных. Получив ответ от БД, приложение возвращает данные обратно по цепочке слоев. Для верификации корректности работы автор извлекает список объектов и использует классическое утверждение `assertEquals`, ожидая увидеть ровно **10 записей**, поскольку именно такое количество тестовых данных было предварительно загружено в базу. Подобный подход позволяет убедиться в отсутствии скрытых багов на стыке слоев архитектуры. Разработчик подчеркивает, что хотя в рамках данного демонстрационного примера рассматривается только сценарий получения полного списка объектов, в реальной практике абсолютно необходимо покрывать аналогичными интеграционными тестами и все остальные **CRUD-операции**: поиск по идентификатору (find by ID), создание (POST), обновление (PUT) и удаление (DELETE) записей. Ранее в разговоре они детально касались общих стратегий тестирования в Spring Boot, однако именно сквозная интеграция с реальной БД дает стопроцентную уверенность в стабильности системы перед деплоем. ### Изолированное тестирование внешних интеграций с помощью @RestClientTest [[JUMP:202:17]] Особый интерес представляет тестирование компонентов, которые взаимодействуют со сторонними API. Автор предлагает детально разобрать специализированный инструмент — аннотацию **`@RestClientTest`**. Этот механизм разработан специально для тестирования REST-клиентов в Spring и позволяет существенно оптимизировать процесс, не загружая полное тяжеловесное окружение приложения. При использовании `@RestClientTest` Spring Boot отключает полную автоконфигурацию контекста, фокусируясь исключительно на тех бинах, которые необходимы для работы `RestTemplateBuilder` или `RestClient.Builder`. В контекст подгружаются только критически важные компоненты, такие как конфигурации для работы с JSON (Jackson или Gson), тогда как стандартные пользовательские бины бизнес-логики игнорируются, что значительно ускоряет запуск тестов. Главное преимущество этой аннотации заключается в том, что разработчик автоматически получает в свое распоряжение настроенный инструмент **`MockRestServiceServer`**. Этот виртуальный сервер позволяет элегантно имитировать ответы от внешних ресурсов. Вместо того чтобы отправлять реальные сетевые запросы к публичным сервисам, таким как JSONPlaceholder, тест перехватывает исходящий вызов и возвращает заранее подготовленный JSON-ответ со статусом успешного выполнения. Написание такого теста строится по популярному шаблону **Given-When-Then** («Дано — Когда — Тогда»), что делает структуру сценария прозрачной и легко читаемой. В процессе живой демонстрации кода автор сталкивается с классической проблемой типов данных, которая часто возникает при интеграции: координатные поля широты и долготы (latitude и longitude) в тестовом объекте адреса были ошибочно объявлены как строки, в то время как ожидался тип `double`. Это приводит к падению сборки с ошибкой несовместимости типов. После оперативного исправления модели данных автор использует мощный инструмент утверждений `assertAll` для одновременной проверки целого набора вложенных полей: имени пользователя, email, адреса, телефона, веб-сайта и компании. С третьей попытки все тесты успешно проходят, подтверждая надежность интеграционного решения. ### Философия разработки и глобальные ресурсы экосистемы Spring [[JUMP:206:57]] Завершая практический блок, посвященный тестированию, инструктор делится важной методологической рекомендацией для начинающих разработчиков. На этапе освоения Spring Boot первоочередной задачей является понимание общей механики и сборка работающего прототипа. Однако как только базовые навыки закреплены, тестирование должно стать неотъемлемой частью повседневной рутины. Более того, автор настоятельно рекомендует практиковать подход **TDD (Test-Driven Development)**, при котором тесты для нового контроллера пишутся еще до реализации самого контроллера. Постоянное повторение этого цикла позволяет довести навык написания качественных тестов до полного автоматизма. Этот масштабный курс подходит к концу, и автор вырачает искреннюю благодарность платформе freeCodeCamp.org за предоставленную площадку, а также всем зрителям за проявленный интерес и упорство. Созданный для курса GitHub-репозиторий задуман как постоянно обновляемый, живой документ. Автор планирует поддерживать его, своевременно обрабатывать поступающие тикеты (issues) и открывать дискуссии для разбора сложных вопросов. Для тех, кто хочет продолжить глубокое погружение в мир корпоративной Java-разработки, автор оставляет обширный список полезных образовательных ресурсов: * Платформа **Spring Academy**, где запущены бесплатные интерактивные руководства, подробно освещающие нововведения Spring Boot 3.2, включая работу с актуальным JDBC Client, обновленным Rest Client и механизмами виртуальных потоков (virtual threads). * Официальный YouTube-канал **Spring Developer**, аккумулирующий терабайты качественного видеоконтента от ведущих инженеров экосистемы. * Портал **spring.io** и официальный **Spring Blog**, позволяющие держать руку на пульсе всех архитектурных изменений. * Еженедельный подкаст **«Spring Office Hours»**, регулярным ведущим которого является сам автор. Подкаст выходит каждый понедельник в 13:00 по восточному времени (EST) на сайте *springofficehours.io* и служит идеальной интерактивной площадкой, куда любой студент может прийти со своими вопросами по пройденному курсу. Выразив признательность своему работодателю Broadcom и всей команде разработки Spring за поддержку в создании этого туториала, автор завершает обучение традиционным и вдохновляющим напутствием: «Happy coding, friends!».