Как определишь кто виноват в неработающем тесте?

Диагностика падающих тестов и определение причины

Когда тест перестаёт работать, нужно быстро выявить, кто виноват: код компонента, сам тест или окружение. Это требует систематического подхода и хороших навыков отладки.

Шаг 1: Запустить тест с полной информацией об ошибке

Сначала получу полный стек ошибки:

# Запустить один конкретный тест с подробным выводом
npm run test:run -- path/to/test.test.tsx --no-coverage

# Запустить с дополнительной информацией
npm run test:run -- --verbose

# Запустить с информацией о времени выполнения
npm run test:run -- --verbose --reporter=verbose

Сообщение об ошибке расскажет, на какой строке код сломался.

Шаг 2: Проверить git историю - что изменилось

Нужно посмотреть, что менялось в файлах:

# Проверить, что изменялось в компоненте
git log -p path/to/Component.tsx | head -100

# Посмотреть последний коммит
git log --oneline -1

# Проверить, что менялось в самом тесте
git log -p path/to/Component.test.tsx | head -50

# Если много файлов изменилось
git diff HEAD~1 --stat

Спросить в команде, кто последний менял компонент или тест.

Шаг 3: Отличить две основные причины

Причина 1: Код сломался (компонент изменился, функцию удалили)
Причина 2: Тест застарел (компонент изменился, тест не обновили)

Для определения:

# Откатить компонент на одну версию вернёмся
git checkout HEAD~1 -- path/to/Component.tsx

# Если тест прошёл - виноват компонент
npm run test:run -- path/to/Component.test.tsx

# Откатить обратно
git checkout -- path/to/Component.tsx

Шаг 4: Анализ самого теста

Часто тест падает из-за неправильных ожиданий:

// Плохой тест - хрупкий, зависит от деталей
test("Button renders", () => {
  const { getByText } = render(<Button>Click</Button>);
  // Проблема: очень зависит от точного текста
  expect(getByText("Click")).toBeInTheDocument();
});

// Хороший тест - проверяет важное поведение
test("Button can be clicked", () => {
  const handleClick = jest.fn();
  const { getByRole } = render(
    <Button onClick={handleClick}>Click</Button>
  );
  
  fireEvent.click(getByRole("button"));
  expect(handleClick).toHaveBeenCalled();
});

// Если компонент пересчитывает рендер асинхронно
test("Async data loads", async () => {
  render(<Component />);
  
  // Ждём элемент вместо немедленного поиска
  const element = await screen.findByText("Loaded");
  expect(element).toBeInTheDocument();
});

Шаг 5: Проверить мокированные зависимости

Часто тесты ломаются, если изменились моки:

// Импортируем компонент, который зависит от API
import { fetchUser } from "@/api";

jest.mock("@/api");

test("Load user data", async () => {
  // Мок вернёт null - компонент сломается
  (fetchUser as jest.Mock).mockResolvedValue(null);
  
  render(<UserComponent />);
  
  // Тест упадёт, если код не ожидает null
  expect(screen.queryByText("User not found")).toBeInTheDocument();
});

Проверить, изменился ли возвращаемый формат моков.

Шаг 6: VCR кассеты для HTTP-запросов

Если используется VCR.py для записи HTTP-ответов:

# Если кассета устарела, удалить и пересчитать
rm tests/fixtures/cassettes/test_name.yaml

# Переписать кассету (первый запуск)
npm run test:run -- --record=new_episodes

Шаг 7: Переменные окружения и конфигурация

# Проверить, не отличаются ли переменные окружения
echo $NODE_ENV
echo $API_URL

# Проверить jest конфигурацию
cat jest.config.js

Практический пример - находим виноватого

// Тест падает с: "Cannot read property map of undefined"
// Причина: API вернула пустой массив, компонент не проверяет []

// Прежде был обработчик ошибок:
const items = data?.items || [];

// Его удалили:
const items = data.items; // СЛОМАЛОСЬ

// Решение 1: Исправить компонент (если это нужно)
const items = data?.items || [];

// Решение 2: Обновить тест, чтобы моковать правильные данные
jest.mock("@/api", () => ({
  fetchItems: jest.fn().mockResolvedValue({ items: [] })
}));

Итого

Процесс диагностики неработающего теста:

1. Запустить с полной ошибкой — npm test --verbose
2. Проверить git историю — кто менял файлы
3. Откатить по частям — определить, код или тест виноват
4. Проверить сам тест — может он неправильный
5. Проверить моки — вернули ли они нужный формат
6. Проверить окружение — ENV переменные, конфигурация
7. Спросить команду — может они знают, что сломали

Главное — не сразу исправлять, а сначала понять корневую причину.