Вопрос с собеседования · Frontend

Как тестировать компоненты с Testing Library?

JuniorВыкатка и эксплуатация
Ещё спрашивают так:
  • Почему не тестировать внутреннее состояние компонента?
Коротко

Принцип Testing Library: тестировать так, как пользуется человек. Компонент рендерят, ищут элементы по роли, подписи, тексту (getByRole('button', { name: 'Отправить' })), действуют через user-event (клик, ввод) и проверяют видимый результат — текст, состояние кнопки, вызов колбэка. Внутреннее состояние и реализацию не трогают — тесты не ломаются при рефакторинге. Поиск по ролям заодно проверяет доступность.

  • findBy — подождать асинхронное появление
  • queryBy — проверить, что элемента нет
  • Сеть подменяют на уровне fetch (MSW), а не моками внутренностей

Подробно

render(<LoginForm onSubmit={onSubmit} />);
await user.type(screen.getByLabelText('Почта'), 'a@b.ru');
await user.click(screen.getByRole('button', { name: 'Войти' }));
expect(onSubmit).toHaveBeenCalledWith({ email: 'a@b.ru' });

Что хотят услышать

  • Тестировать как пользователь.
  • Поиск по ролям и подписям.
  • Не проверять реализацию.

Проверьте себя

Один верный вариант. Подумайте, потом откройте ответ.

Показать варианты и ответ
  • ✓Рендерить, искать по роли и подписи, действовать как пользователь
  • ✗Проверять внутреннее состояние и приватные методы компонента напрямую
  • ✗Искать элементы по CSS-классам и вложенности тегов из текущей реализации
  • ✗Testing Library работает только в e2e-тестах с настоящим браузером

Связанные вопросы

Партнёр платформы

Разбор собеседования с sotto

После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.

Разбор собеседования