Почему не нравятся интеграционные тесты?

Почему интеграционные тесты вызывают сложности

Интеграционные тесты часто называют проблемным подходом в индустрии. Это справедливо по нескольким причинам:

Медленность

Интеграционные тесты выполняются долго, потому что они работают с реальными зависимостями:

// Интеграционный тест — долгий
@SpringBootTest
public class UserServiceIntegrationTest {
    @Test
    void testUserSave() throws InterruptedException {
        // Ждём подключения к БД
        // Ждём ответа от сервиса
        // Ждём миграции
        userService.save(user);
        Thread.sleep(1000);  // Может быть вообще нужна
    }
}

Время выполнения может быть в 100+ раз медленнее unit-тестов. На проекте с 1000 интеграционными тестами запуск может занять часы.

Нестабильность и flakiness

Интеграционные тесты зависят от множества внешних факторов:

// Что может сломать этот тест?
@Test
void testApiCall() {
    // 1. БД не поднялась
    // 2. Network timeout
    // 3. Другой тест заблокировал ресурс
    // 4. Race condition в параллельном выполнении
    // 5. Данные из другого теста помешали
    Response response = apiClient.get("/data");
    assertEquals(200, response.getStatus());
}

Тесты падают не из-за бага в коде, а из-за окружения. Это разочаровывает разработчиков.

Сложность настройки и поддержки

// Нужно поднять целую инфраструктуру
@SpringBootTest
@Testcontainers
public class ComplexIntegrationTest {
    @Container
    static PostgreSQLContainer<?> postgres = 
        new PostgreSQLContainer<>("postgres:latest");
    
    @Container
    static GenericContainer<?> redis = 
        new GenericContainer<>("redis:latest")
        .withExposedPorts(6379);
    
    // Docker требуется на CI/CD
    // Конфигурация усложняется
    // Maintenance nightmare
}

Плохая локализация ошибок

Когда интеграционный тест падает, неясно что именно сломалось:

@Test
void complexWorkflow() {
    user = userService.save(user);        // Может упасть тут
    profile = profileService.create(user); // Или тут
    notification.send(profile);             // Или тут
    cache.invalidate();                     // Или даже тут
    // FAIL — но не ясно где!
}

Unit-тест тестирует одну функцию, интеграционный — слишком много.

Дублирование логики

Теже проверки делаются в unit-тестах и интеграционных:

// Unit-тест
@Test
void calculatorAdd() {
    assertEquals(4, calculator.add(2, 2));
}

// Интеграционный тест — зачем?
@Test
@SpringBootTest
void calculatorAddIntegration() {
    assertEquals(4, calculator.add(2, 2));
}

Тестирование деталей реализации

// Зачем нам знать, что используется PostgreSQL?
@Test
void testDatabaseConnection() {
    assertTrue(dataSource.getConnection().isValid(1));
}

// Правильнее тестировать поведение
@Test
void testUserCanBeSaved() {
    userRepository.save(user);
    assertTrue(userRepository.exists(user.getId()));
}

Лучший подход: Pyramid of Tests

      E2E (мало)
     /      \
   Integration (среднее)
   /          \
Unit (много)

Unit-тесты: 70% — тестируют бизнес-логику в изоляции с mocks

Integration-тесты: 20% — проверяют взаимодействие между компонентами

E2E-тесты: 10% — проверяют критические пути пользователя

Правильное использование интеграционных тестов

// ХОРОШО — тестируем реальное взаимодействие
@SpringBootTest
@Transactional
public class UserRepositoryIntegrationTest {
    @Autowired
    private UserRepository repo;
    
    @Test
    void testComplexQuery() {
        // Тестируем только то, что невозможно в unit-тесте
        List<User> active = repo.findActiveByDepartment("IT");
        assertFalse(active.isEmpty());
    }
}

// ПЛОХО — это должен быть unit-тест
@SpringBootTest
public class SimpleLogicIntegrationTest {
    @Test
    void testSimpleAddition() {
        assertEquals(4, 2 + 2);
    }
}

Вывод

Интеграционные тесты полезны, но их должно быть мало и они должны проверять только то, что невозможно протестировать в unit-тестах. Основу test suite должны составлять быстрые, надёжные unit-тесты с mocks.