Что проверяешь в интеграционном тесте?

Что проверяю в интеграционном тесте

В интеграционных тестах я проверяю корректность взаимодействия нескольких независимых модулей или систем после их объединения. Цель — убедиться, что части приложения, которые успешно работают по отдельству (благодаря unit-тестам), правильно взаимодействуют друг с другом, формируя целостный функциональный поток. Это критически важно для Frontend Developer, поскольку фронтенд часто интегрируется с бэкендом, сторонними API и внутренними сервисами.

Ключевые аспекты для проверки

1. Интеграция с бэкендом (API)

    *   **Корректность запросов и ответов:** Проверяю, что фронтенд отправляет правильно структурированные HTTP-запросы (метод, заголовки, тело), а получаемые ответы корректно обрабатываются.

```javascript
// Пример теста для проверки работы с API
describe('User API Integration', () => {
  it('should fetch user data and update UI', async () => {
    // Мокаем ответ API, но проверяем логику интеграции
    const mockUser = { id: 1, name: 'John Doe' };
    jest.spyOn(global, 'fetch').mockResolvedValue({
      ok: true,
      json: async () => mockUser,
    });

    await fetchUserData(1);
    // Проверяем, что состояние приложения обновилось правильно
    expect(store.getState().user).toEqual(mockUser);
  });
});
```

    *   **Обработка ошибок:** Убеждаюсь, что фронтенд корректно реагирует на ошибки API (например, статусы 4xx/5xx), показывая пользователю соответствующие сообщения без "падения" интерфейса.

1. Интеграция между компонентами и стейт.Mенеджментом

    *   Проверяю, как **компоненты UI** взаимодействуют с глобальным состоянием (например, **Redux**, **Context**, **Vuex**). Тест может имитировать действие пользователя и проверять цепочку: `dispatch(action) -> изменение state -> корректное обновление компонента`.

```javascript
// Пример: тест интеграции компонента с Redux
test('should display list after adding item via store', () => {
  render(<TodoList />, { wrapper: ReduxProvider });
  // Симулируем действие, которое диспатчит в Redux
  fireEvent.click(screen.getByText('Add Task'));
  // Проверяем, что компонент отобразил новое состояние из store
  expect(screen.getByText('New Task')).toBeInTheDocument();
});
```

3. Интеграция с внешними сервисами и библиотеками

    *   Тестирую работу с **сторонними библиотеками** (например, карты, графики) или сервисами (Analytics, Payment Gateways). Убеждаюсь, что их инициализация, конфигурация и вызовы методов происходят корректно в контексте моего приложения, без конфликтов или неожиданных ошибок.

1. Интеграция маршрутизации (Routing)

    *   Проверяю, что переходы между **роутами** работают правильно: меняется URL, отображается соответствующий компонент, сохраняется или корректно передается состояние (например, через query-параметры). Это часто требует тестирования в **специальном окружении**, имитирующем браузер.

1. Совместная работа нескольких модулей над одной бизнес-логикой

    *   Это основное! Например, тест процесса "Оформление заказа":
        *   Модуль **корзины** передает данные модулю **форм**.
        *   Модуль **форм** отправляет их на **бэкенд**.
        *   Модуль **уведомлений** показывает результат пользователю.
    Я проверяю, что вся цепочка выполняется без ошибок и с ожидаемым конечным результатом.

Чем интеграционные тесты отличаются от unit и e2e?

• Unit-тесты: Проверяют одну функцию, модуль или компонент изолированно (все зависимости замоканы). Сосредоточены на внутренней логике.
• Интеграционные тесты: Проверяют группу модулов вместе, с частичным или реальным использованием зависимостей (например, реальный store, но замоканный API). Это "средний" уровень.
• E2E-тесты (например, через Cypress): Проверяют полное приложение в среде, максимально близкой к реальной (браузер, реальный бэкенд). Это "верхний" уровень, проверяющий поведение для пользователя.

Практический подход на фронтенде

Я часто использую Jest в сочетании с React Testing Library или Vue Test Utils для таких тестов. Ключевой принцип — не мокать всё, но мокать то, что находится вне контроля текущего тестируемого "интеграционного слоя" (например, сетевые запросы). Это позволяет:

• Найти проблемы взаимодействия между модулями (например, несоответствие формата данных).
• Убедиться в корректности потоков данных (state -> props -> rendering).
• Снизить количество дефектов после сборки приложения из проверенных unit-тестами частей.

Итог: Интеграционные тесты — это проверка "цемента", который скрепляет отдельные "кирпичи" (модули) в прочное и работоспособное приложение. Они заполняют критический пробел между unit и e2e-тестами, обеспечивая уверенность в том, что система работает как единое целое.