Что делать на компонентном уровне тестирования

Стратегия компонентного тестирования: фокус на изоляции и контрактах

На компонентном уровне тестирования (Component Testing, или модульное тестирование для UI) мы работаем с отдельными, изолированными частями пользовательского интерфейса. Ключевая идея — тестировать компонент в отрыве от его внешних зависимостей (серверов API, глобального состояния, дочерних компонентов), чтобы убедиться в корректности его внутренней логики, рендеринга и обработки событий.

Основные цели и подходы

Основная цель — проверить, что компонент:

• Корректно отображает UI при различных пропсах (props) и состояниях.
• Правильно реагирует на пользовательские события (клики, ввод данных).
• Корректно взаимодействует с переданными колбеками (callbacks).
• Соответствует своему публичному контракту (интерфейсу).

Для этого используется комбинация подходов:

1. Изоляция зависимостей: Заменяем реальные сервисы, модули и дочерние компоненты на моки (mocks), стабы (stubs) и шпионы (spies). Это позволяет тестировать компонент в предсказуемом окружении.
2. Рендеринг в памяти: Компонент рендерится не в реальном браузере, а в изолированной среде (например, с помощью JSDOM или виртуальной машины JavaScript).
3. Использование утилит для тестирования UI: Например, React Testing Library (RTL) или Vue Test Utils. Они предоставляют API для рендеринга, поиска элементов в DOM и симуляции событий.

Практические задачи на компонентном уровне

Вот что конкретно следует проверять и как это реализовать:

1. Проверка рендеринга (Render Testing)

Убедиться, что компонент отображает ожидаемый контент на основе полученных пропсов.

// Пример на React Testing Library
import { render, screen } from '@testing-library/react';
import { WelcomeMessage } from './WelcomeMessage';

test('отображает приветствие с именем пользователя', () => {
  // Рендерим компонент с конкретным пропсом `username`
  render(<WelcomeMessage username="Анна" />);
  // Ищем ожидаемый текст в виртуальном DOM
  const greetingElement = screen.getByText(/добро пожаловать, анна!/i);
  // Утверждаем, что элемент присутствует в документе
  expect(greetingElement).toBeInTheDocument();
});

2. Тестирование пользовательских событий (Event Handling Testing)

Симулировать действия пользователя и проверять реакцию компонента: вызов колбеков, изменение состояния, обновление UI.

import { render, screen, fireEvent } from '@testing-library/react';
import { Counter } from './Counter';

test('увеличивает счетчик при клике на кнопку', () => {
  render(<Counter />);
  const button = screen.getByRole('button', { name: /увеличить/i });
  const countDisplay = screen.getByText(/текущее значение:/i);

  expect(countDisplay).toHaveTextContent('0'); // Начальное состояние
  fireEvent.click(button); // Симуляция клика
  expect(countDisplay).toHaveTextContent('1'); // Проверка результата
});

3. Тестирование побочных эффектов и асинхронного поведения

Проверять логику, связанную с useEffect, вызовами API (замоканными), таймерами.

import { render, screen, waitFor } from '@testing-library/react';
import { UserProfile } from './UserProfile';
import { fetchUser } from './api';

// Мокаем модуль API
jest.mock('./api');

test('отображает данные пользователя после загрузки', async () => {
  // Задаем возвращаемое значение мок-функции
  fetchUser.mockResolvedValue({ name: 'Иван', email: 'ivan@test.com' });

  render(<UserProfile userId="123" />);

  // Вначале может быть состояние загрузки
  expect(screen.getByText(/загрузка.../i)).toBeInTheDocument();

  // Ждем появления асинхронного контента
  await waitFor(() => {
    expect(screen.getByText('Иван')).toBeInTheDocument();
    expect(screen.getByText('ivan@test.com')).toBeInTheDocument();
  });
  // Проверяем, что мок был вызван с правильным аргументом
  expect(fetchUser).toHaveBeenCalledWith('123');
});

4. Тестирование условного рендеринга

Проверка отображения разных ветвей UI в зависимости от пропсов или состояния.

test('отображает сообщение об ошибке при передаче пропса `error`', () => {
  const { rerender } = render(<DataWidget error={null} />);
  expect(screen.queryByRole('alert')).not.toBeInTheDocument(); // Ошибки нет

  // Ре-рендерим компонент с новым пропсом
  rerender(<DataWidget error="Соединение потеряно" />);
  expect(screen.getByRole('alert')).toHaveTextContent('Соединение потеряно');
});

5. Верификация взаимодействия (Interaction Testing)

Проверка, что компонент корректно вызывает функции, переданные ему извне (например, из родительского компонента).

test('вызывает обработчик onSubmit с введенными данными формы', () => {
  // Создаем mock-функцию шпион
  const handleSubmit = jest.fn();
  render(<LoginForm onSubmit={handleSubmit} />);

  fireEvent.change(screen.getByLabelText(/email/i), {
    target: { value: 'test@example.com' },
  });
  fireEvent.change(screen.getByLabelText(/пароль/i), {
    target: { value: 'secret123' },
  });
  fireEvent.click(screen.getByRole('button', { name: /войти/i }));

  // Проверяем, что колбек был вызван ровно один раз с конкретными аргументами
  expect(handleSubmit).toHaveBeenCalledTimes(1);
  expect(handleSubmit).toHaveBeenCalledWith({
    email: 'test@example.com',
    password: 'secret123',
  });
});

Ключевые инструменты и библиотеки

• Jest: Основной фреймворк для запуска тестов, утверждений (assertions) и мокинга модулей.
• React Testing Library / Vue Test Utils / Angular Testing Library: Специализированные утилиты для рендеринга и взаимодействия с компонентами конкретных фреймворков.
• Testing Playground / Chrome Extension: Инструменты для поиска оптимальных селекторов (по ролям, тексту) для тестов.

Резюме

На компонентном уровне тестирования QA-инженер или разработчик фокусируется на поведении отдельного "кирпичика" UI. Основная работа заключается в создании изолированного тестового окружения, симуляции пользовательских сценариев и проверке соответствия компонента его техническому заданию. Такой подход позволяет находить дефекты на ранней стадии, обеспечивает быструю обратную связь при рефакторинге и формирует прочный фундамент для последующего интеграционного и E2E-тестирования. Успешное компонентное тестирование напрямую влияет на стабильность и поддерживаемость кодовой базы.