🧪 Тестирование в Spring Boot: Спите спокойно
Глобально тесты делятся на два лагеря:
1. Unit-тесты (Модульные): Быстрые, изолированные. Проверяем только логику одного класса (обычно Service). Никаких баз данных и поднятия Spring Context.
2. Integration-тесты (Интеграционные): Проверяем, как компоненты работают вместе (Controller + Service + DB). Здесь поднимается Spring Context.
⚡ 1. Unit-тесты: Изоляция и Скорость
Когда вы тестируете
Для этого мы используем Mockito - библиотеку, которая создает "фейковые" объекты (моки).
Ключевые аннотации:
🔴
🔴
🔴
💻 Пример Unit-теста:
🐢 2. Integration-тесты: Тяжелая артиллерия
Иногда нужно проверить, правильно ли мапится JSON в контроллере или работает ли SQL-запрос. Тут нам нужен Spring Context.
Ключевые аннотации:
🔴
🔴
🔴
💻 Пример теста Контроллера (
⚔️
Это самый частый вопрос.
1.
2.
🔥 Итог
🔴 Пишите много Unit-тестов (они быстрые). Используйте
🔴 Пишите немного Integration-тестов (они проверяют связки). Используйте
🔴 Никогда не тестируйте внешней API или боевую БД - мокайте их!
#SpringBoot #Testing #JUnit5 #Mockito #QualityAssurance
📲 Мы в MAX
👉@BookJava
Глобально тесты делятся на два лагеря:
1. Unit-тесты (Модульные): Быстрые, изолированные. Проверяем только логику одного класса (обычно Service). Никаких баз данных и поднятия Spring Context.
2. Integration-тесты (Интеграционные): Проверяем, как компоненты работают вместе (Controller + Service + DB). Здесь поднимается Spring Context.
⚡ 1. Unit-тесты: Изоляция и Скорость
Когда вы тестируете
UserService, вам не нужно, чтобы он реально лез в базу данных. Вам нужно проверить: "Если репозиторий вернет null, выбросит ли сервис ошибку?"Для этого мы используем Mockito - библиотеку, которая создает "фейковые" объекты (моки).
Ключевые аннотации:
@ExtendWith(MockitoExtension.class) - включаем Mockito.@Mock - "Создай фейковый объект" (например, UserRepository).@InjectMocks - "Создай тестируемый объект (UserService) и вставь в него моки".💻 Пример Unit-теста:
@ExtendWith(MockitoExtension.class) // 1. Включаем Mockito
class UserServiceTest {
@Mock
private UserRepository userRepository; // Фейк
@InjectMocks
private UserService userService; // Реальный сервис с фейком внутри
@Test
void shouldReturnUser_WhenExists() {
// GIVEN (Дано) - Настраиваем поведение мока
User mockUser = new User("Alex");
// "Если кто-то вызовет findById(1), верни mockUser"
Mockito.when(userRepository.findById(1L)).thenReturn(Optional.of(mockUser));
// WHEN (Когда) - Вызываем метод сервиса
User result = userService.findById(1L);
// THEN (Тогда) - Проверяем результат
Assertions.assertEquals("Alex", result.getName());
// Проверяем, что метод репозитория действительно вызывался 1 раз
Mockito.verify(userRepository, times(1)).findById(1L);
}
}
🐢 2. Integration-тесты: Тяжелая артиллерия
Иногда нужно проверить, правильно ли мапится JSON в контроллере или работает ли SQL-запрос. Тут нам нужен Spring Context.
Ключевые аннотации:
@SpringBootTest - Поднимает весь контекст приложения (тяжело и медленно, но честно).@WebMvcTest - Поднимает только веб-слой (Контроллеры). Сервисы и БД не грузятся.@MockBean - Главная магия Spring Test. Это как @Mock, только этот мок кладется прямо в Spring Context, заменяя собой настоящий бин.💻 Пример теста Контроллера (
@WebMvcTest):
@WebMvcTest(UserController.class) // Грузим только контроллер
class UserControllerTest {
@Autowired
private MockMvc mockMvc; // Инструмент для имитации HTTP-запросов
@MockBean // Заменяем настоящий сервис заглушкой в контексте Spring
private UserService userService;
@Test
void shouldReturnStatus200() throws Exception {
Mockito.when(userService.findById(1L)).thenReturn(new User("Alex"));
mockMvc.perform(get("/users/1")) // Делаем GET запрос
.andExpect(status().isOk()) // Ждем 200 OK
.andExpect(jsonPath("$.name").value("Alex")); // Проверяем JSON
}
}
⚔️
@Mock vs @MockBean - Не путать!Это самый частый вопрос.
1.
@Mock (из org.mockito): Используется в Unit-тестах. Быстро. Spring про него ничего не знает.2.
@MockBean (из spring-boot-test): Используется в Integration-тестах. Spring находит этот бин в контексте и подменяет его на мок. Медленнее.🔥 Итог
Mockito.when(...).MockMvc.#SpringBoot #Testing #JUnit5 #Mockito #QualityAssurance
📲 Мы в MAX
👉@BookJava
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
📦 От Кода к Продакшену: JAR и Docker
В старые времена (Java EE) процесс деплоя был адом: нужно было установить на сервер Tomcat, настроить его, скомпилировать
Spring Boot принес концепцию Fat JAR (Жирный JAR).
🍔 1. Fat JAR - "Всё своё ношу с собой"
Spring Boot упаковывает ваше приложение, все библиотеки (зависимости) и даже сам веб-сервер (Tomcat) в один единственный файл
Этот файл работает как
Как собрать?
В терминале (в папке проекта):
В папке
Как запустить?
Где угодно (на сервере, на ноутбуке друга), где есть Java:
Всё! Сервер стартует.
🐳 2. Docker - "Работает везде"
JAR это хорошо. Но что, если на сервере стоит Java 11, а у вас Java 17? Или другая ОС? Начинается проблема "На моем компьютере работало!".
Docker решает это, упаковывая ваше приложение вместе с Java и операционной системой в Контейнер.
Пишем
Создайте файл без расширения с именем
Вариант для новичков (Простой):
Как запустить:
🏗 3. Multi-stage Build (Уровень Pro)
В варианте выше вам нужно сначала собрать JAR руками. Это неудобно для CI/CD.
В профессиональном Dockerfile мы делаем сборку внутри Docker.
Почему это круто? В финальном образе нет исходного кода и тяжелого Maven. Только Java и ваш JAR. Образ весит минимум, а собрать его можно одной командой
🔥 Итог
1. Maven/Gradle собирают код в один Fat JAR.
2. Dockerfile описывает среду для запуска.
3. Multi-stage build позволяет собирать и запускать приложение в изолированной среде, не засоряя систему.
#SpringBoot #Docker #DevOps #Deployment #Java
📲 Мы в MAX
👉@BookJava
В старые времена (Java EE) процесс деплоя был адом: нужно было установить на сервер Tomcat, настроить его, скомпилировать
.war файл, закинуть его в папку... 🤯Spring Boot принес концепцию Fat JAR (Жирный JAR).
🍔 1. Fat JAR - "Всё своё ношу с собой"
Spring Boot упаковывает ваше приложение, все библиотеки (зависимости) и даже сам веб-сервер (Tomcat) в один единственный файл
.jar.Этот файл работает как
.exe в Windows. Ему ничего не нужно, кроме установленной Java.Как собрать?
В терминале (в папке проекта):
# Для Maven
./mvnw clean package
# Для Gradle
./gradlew build
В папке
target (или build/libs) появится файл myapp-0.0.1-SNAPSHOT.jar.Как запустить?
Где угодно (на сервере, на ноутбуке друга), где есть Java:
java -jar myapp.0.0.1-SNAPSHOT.jar
Всё! Сервер стартует.
🐳 2. Docker - "Работает везде"
JAR это хорошо. Но что, если на сервере стоит Java 11, а у вас Java 17? Или другая ОС? Начинается проблема "На моем компьютере работало!".
Docker решает это, упаковывая ваше приложение вместе с Java и операционной системой в Контейнер.
Пишем
DockerfileСоздайте файл без расширения с именем
Dockerfile в корне проекта.Вариант для новичков (Простой):
# 1. Берем базовый образ с Java 17 (легковесный Alpine Linux)
FROM eclipse-temurin:17-jre-alpine
# 2. Копируем наш JAR внутрь образа
# (Предварительно нужно сделать mvn package руками!)
COPY target/*.jar app.jar
# 3. Говорим, какую команду запустить при старте контейнера
ENTRYPOINT ["java", "-jar", "/app.jar"]
Как запустить:
# 1. Собираем образ (Image)
docker build -t my-spring-app .
# 2. Запускаем контейнер
# -p 8080:8080 пробрасывает порт наружу
docker run -p 8080:8080 my-spring-app
🏗 3. Multi-stage Build (Уровень Pro)
В варианте выше вам нужно сначала собрать JAR руками. Это неудобно для CI/CD.
В профессиональном Dockerfile мы делаем сборку внутри Docker.
# --- Этап 1: Сборка (Build) ---
FROM maven:3.8.5-openjdk-17 AS builder
WORKDIR /app
COPY . .
# Собираем JAR, пропуская тесты (для скорости)
RUN mvn clean package -DskipTests
# --- Этап 2: Запуск (Run) ---
# Берем чистый, маленький образ для запуска
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# Копируем ТОЛЬКО готовый jar из первого этапа
COPY --from=builder /app/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]
Почему это круто? В финальном образе нет исходного кода и тяжелого Maven. Только Java и ваш JAR. Образ весит минимум, а собрать его можно одной командой
docker build, даже если на компьютере вообще не установлена Java!🔥 Итог
1. Maven/Gradle собирают код в один Fat JAR.
2. Dockerfile описывает среду для запуска.
3. Multi-stage build позволяет собирать и запускать приложение в изолированной среде, не засоряя систему.
#SpringBoot #Docker #DevOps #Deployment #Java
📲 Мы в MAX
👉@BookJava
👍6❤1