TDD и написание тестируемого кода

↑ 6.3 Качество кода и тестирование: продвинутый уровень · ← Предыдущая · → Следующая

Желательно~3 мин чтенияУровень: middle

Зачем это на собесе

Middle-разработчику важно не «пишу ли я TDD», а умение делать код тестируемым и выбирать уровень теста.

Цикл TDD

1. Red — пишем падающий тест на желаемое поведение.
2. Green — минимальный код, чтобы он прошёл.
3. Refactor — улучшаем код при зелёных тестах.

Плюсы: дизайн от потребителя, быстрая обратная связь, регрессионная сетка. Минусы: не подходит для исследовательского прототипирования и UI-вёрстки.

Тестируемый код

• чистые функции отделяем от побочных эффектов;
• зависимости (HTTP, время, случайность) внедряем, а не создаём внутри;
• компоненты остаются тонкими: логика — в composables и сервисах;
• не тестируем детали реализации, только поведение.

// плохо: время и сеть зашиты
export async function isTokenFresh() {
  const t = await fetch('/token').then(r => r.json())
  return Date.now() < t.exp
}
 
// хорошо: зависимости передаются
export const isTokenFresh = (exp: number, now: () => number = Date.now) => now() < exp

Пирамида тестов

Уровень	Скорость	Что проверяет
Unit	мс	функции, composables, сторы
Component	десятки мс	компонент в изоляции (Vue Test Utils, Testing Library)
Integration	сотни мс	несколько модулей, мок сети (MSW)
E2E	секунды	сценарий пользователя в браузере

Больше быстрых нижних уровней, меньше хрупких E2E.

Практика тестов

• имя теста описывает поведение: «показывает ошибку, если email пустой»;
• Arrange–Act–Assert;
• запросы по роли и тексту (getByRole), а не по CSS-классам;
• мок сети через MSW, а не мок fetch в каждом тесте.

Вопросы с ответами

Как сделать компонент тестируемым?

Вынести логику в composables, зависимости внедрять через props, provide/inject или параметры, побочные эффекты изолировать на границе.

Что не стоит тестировать?

Детали реализации (внутренние методы, состояние), сторонние библиотеки, тривиальные геттеры. Тест должен переживать рефакторинг.