Какие тесты вы писали?

Вопрос "Какие тесты вы писали?" не про то, сколько названий библиотек вы помните. Хороший ответ показывает три вещи. Что вы проверяли, зачем это было нужно и как сделали тест надежным.

Удобная структура ответа:

1. Назовите уровни тестов, с которыми работали.
2. Для каждого уровня дайте короткую цель.
3. Выберите один конкретный пример.
4. Скажите, какой баг или регрессию такой тест мог поймать.
5. Честно обозначьте границу опыта.

Так вы не выглядите человеком, который просто видел Jest в package.json. Вы показываете, что воспринимаете тест как защиту продукта от конкретного риска.

Не надо придумывать, что вы писали все виды тестов в большом продакшене. Если реальный опыт был только с unit-тестами и компонентами, это можно подать сильно. Главное, объяснить, почему вы выбирали такие тесты и что они проверяли.

Пример ответа, если опыт был на проекте:

Я писал unit-тесты для функций форматирования и валидации, компонентные тесты для React-форм через React Testing Library и несколько интеграционных тестов на сценарии с API-моком. Например, для формы регистрации проверял обязательные поля, disabled-состояние кнопки, успешную отправку и ошибку сервера. Это помогало ловить регрессии в валидации и не выпускать форму, которая визуально работает, но отправляет неправильные данные.

Пример ответа, если опыт был меньше:

В коммерческом проекте я в основном работал с компонентными тестами и небольшими unit-тестами. E2E настраивал только в учебном проекте, поэтому не буду выдавать это за большой продакшен-опыт. Но я понимаю, что e2e лучше использовать для критичных потоков вроде логина или оформления заказа, а не для проверки каждой кнопки.

Для frontend обычно хватает четырех групп, если вы можете объяснить их на примерах.

Unit-тесты проверяют маленькую часть логики. Утилиту, валидацию, reducer, функцию преобразования данных. Их плюс в скорости и понятной причине падения. Практический риск, который они закрывают, это тихая поломка бизнес-правила.

Компонентные тесты проверяют UI через поведение. Что пользователь вводит, нажимает и видит. Для React это часто React Testing Library. Риск, который они закрывают, это сломанная форма, неправильное сообщение об ошибке, недоступная кнопка, потерянный фокус, отсутствие label или неверное состояние загрузки.

Интеграционные тесты проверяют связку нескольких частей. Компонент, состояние, роутинг, API-мок. Они полезны, когда баг появляется не в одной функции, а на границе между слоями.

E2E тесты проверяют полный пользовательский путь в браузере. Их стоит привязывать к дорогим ошибкам. Пользователь не может войти, оформить заказ, отправить заявку или пройти оплату. Такие тесты дают уверенность, но требуют больше времени и дисциплины с тестовыми данными.

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

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { vi } from "vitest";
import { LoginForm } from "./LoginForm";

test("shows validation error for empty password", async () => {
  const user = userEvent.setup();
  const onSubmit = vi.fn();

  render(<LoginForm onSubmit={onSubmit} />);

  await user.type(screen.getByLabelText(/email/i), "user@example.com");
  await user.click(screen.getByRole("button", { name: /sign in/i }));

  expect(await screen.findByText(/password is required/i)).toBeInTheDocument();
  expect(onSubmit).not.toHaveBeenCalled();
});

Здесь вы можете сказать так. Я не проверяю внутренний state формы. Я проверяю то, что важно пользователю и продукту. Без пароля форма показывает ошибку и не отправляет данные. Такой тест переживет рефакторинг внутренней реализации, если поведение останется тем же.

Если вы упоминаете тесты с API, сразу покажите, что понимаете источник нестабильности. В компонентных и интеграционных тестах реальный backend обычно не нужен. Он делает тест зависимым от сети, данных и окружения. Еще один риск, это гонка запросов. Пользователь меняет фильтр, старый ответ приходит позже и перетирает новые данные.

Сильная формулировка:

Для API-сценариев я мокал ответы и проверял состояния интерфейса: loading, success, empty и error. Например, при 500 ожидал сообщение об ошибке и доступную повторную отправку. Для поиска или фильтров проверял, что устаревший ответ не перезаписывает новый результат. В e2e уже можно проверять реальную или тестовую связку, но там нужны стабильные тестовые данные и очистка после сценария.

Важно не говорить только, что вы проверяли вызов fetch. Вызов функции сам по себе не значит, что пользователь увидел правильный экран. Лучше проверять результат в UI.

Зрелый ответ отличается не количеством библиотек, а осознанными ограничениями. Можно прямо сказать, что быстрые unit и компонентные тесты хорошо подходят для частых запусков в pull request. E2E лучше держать для критичных потоков, потому что они медленнее, требуют тестовых данных и чаще ломаются от окружения.

Если вас спрашивают про CI, не надо уходить в DevOps-лекцию. Достаточно сказать, какие тесты запускались на каждый PR, какие отдельно, как команда смотрела отчеты и что вы делали с flaky-тестами. Это показывает, что вы думали не только о написании теста, но и о его жизни в проекте.

Подготовьте заранее 2-3 своих примера. Один про маленькую логику, один про React-компонент, один про пользовательский сценарий. Для каждого примера держите короткую формулу. Что проверяли, каким инструментом, какой риск закрывали, что было бы плохим сигналом.

Не пытайтесь звучать старше своего опыта. Если вы честно говорите о границах, но объясняете trade-off и можете разобрать пример, ответ выглядит сильнее, чем набор громких слов без деталей.