Как организовать тестирование библиотеки UI-компонентов?

UI-библиотека компонентов — это фундамент, на котором строятся десятки приложений, поэтому ошибка в одном компоненте может разойтись по всей продуктовой линейке. Тестирование такой библиотеки отличается от тестирования обычного приложения: здесь важны не бизнес-сценарии, а поведение самого компонента, его API (пропсы, события, слоты) и визуальная стабильность.

Уровни тестирования

• Unit-тесты — проверяют чистую логику: вычисления, хелперы, редьюсеры, форматирование.
• Компонентные тесты — рендер компонента, реакция на пропсы, вызов колбэков, состояния disabled/loading.
• Интеграционные тесты — взаимодействие нескольких компонентов (например, Select внутри Form).
• Визуальные (snapshot) тесты — сравнение скриншотов, чтобы поймать неожиданные изменения стилей.
• Accessibility-тесты — проверка ARIA-ролей, фокуса, клавиатурной навигации.

Пример компонентного теста

Используем React Testing Library и Jest: проверяем, что кнопка вызывает onClick и блокируется при disabled.

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

test('вызывает onClick при клике', () => {
  const onClick = jest.fn();
  render(<Button onClick={onClick}>OK</Button>);
  fireEvent.click(screen.getByRole('button', { name: 'OK' }));
  expect(onClick).toHaveBeenCalledTimes(1);
});

test('не вызывает onClick при disabled', () => {
  const onClick = jest.fn();
  render(<Button disabled onClick={onClick}>OK</Button>);
  fireEvent.click(screen.getByRole('button'));
  expect(onClick).not.toHaveBeenCalled();
});

Визуальные тесты и Storybook

Каждый компонент описывается сторисом в Storybook, а Chromatic или Playwright делает скриншоты всех состояний. При изменении кода CI сравнивает новые скриншоты с эталонными и подсвечивает diff. Это ловит регрессии в CSS, которые не видны в jsdom.

Автоматизация в CI

1. Линт и типы (ESLint, TypeScript).
2. Unit и компонентные тесты (Jest + RTL).
3. Визуальные тесты (Chromatic/Playwright).
4. Accessibility (axe-core, jest-axe).
5. Публикация пакета только при зелёном пайплайне.

Итог: тестирование UI-библиотеки стоит строить как пирамиду — много быстрых unit и компонентных тестов, меньше интеграционных и визуальных, плюс обязательные accessibility-проверки. Такой подход даёт уверенность при рефакторинге и защищает потребителей библиотеки от регрессий.