Какие типы тестов должен писать разработчик в процессе разработки?

Разработчик должен писать тесты, обеспечивающие надежность кода на разных уровнях. Основные типы:

1. Модульные тесты (Unit Tests) — ОСНОВА

• Цель: Проверить корректность работы отдельного класса или метода в изоляции.
• Что тестировать: Логика бизнес-сервисов, утилитарные методы, преобразователи данных.
• Обязанность: Писать в первую очередь, часто по методологии TDD (Test-Driven Development).

• Пример (JUnit + Mockito):

  @Test
  void transferMoney_ShouldUpdateBalances() {
  // Arrange: Создаем заглушки (mocks) и тестовые данные
  AccountRepository accRepoMock = mock(AccountRepository.class);
  TransferService service = new TransferService(accRepoMock);
  Account from = new Account("1", 100.0);
  Account to = new Account("2", 50.0);
  
  when(accRepoMock.findById("1")).thenReturn(Optional.of(from));
  when(accRepoMock.findById("2")).thenReturn(Optional.of(to));
  
  // Act: Вызываем тестируемый метод
  service.transfer("1", "2", 30.0);
  
  // Assert: Проверяем результат и взаимодействие
  assertEquals(70.0, from.getBalance()); // Проверка состояния
  assertEquals(80.0, to.getBalance());
  verify(accRepoMock).save(from); // Проверка вызова зависимостей
  verify(accRepoMock).save(to);
  }

2. Интеграционные тесты (Integration Tests)

• Цель: Проверить взаимодействие нескольких компонентов (например, сервиса с реальным репозиторием и БД).
• Что тестировать: Работа Spring-бинов вместе, корректность маппинга JPA-сущностей, вызов внешних REST API.
• Обязанность: Писать для критических путей интеграции.

3. Сквозные тесты (End-to-End Tests)

• Цель: Проверить ключевые пользовательские сценарии от начала до конца (например, «создание заказа» через UI или API).
• Обязанность: Писать ограниченное количество для основных бизнес-потоков, так как они медленные и хрупкие.

Ключевые принципы для разработчика:

• Пирамида тестирования: Много unit-тестов, меньше интеграционных, еще меньше E2E.
• F.I.R.S.T.: Тесты должны быть Fast (быстрыми), Isolated (изолированными), Repeatable (повторяемыми), Self-validating (самодостаточными), Timely (своевременными).
• Покрытие кода: Стремиться к высокому покрытию unit-тестами критической бизнес-логики.
• Читаемость: Тест должен служить документацией и четко отвечать на вопросы: Что тестируется? При каких условиях? Каков ожидаемый результат?