Tdd

Skill: tdd

Test-Driven Development по циклу Red → Green → Refactor. Не догма, а инструмент: применяй где это реально ускоряет, а не где «положено».

Когда применять

Любое из:

• Новая чистая функция (вход → выход) — расчёт, валидатор, парсер, конвертер.
• Бизнес-логика с понятными правилами (скидки, цены, лимиты, доступы).
• Багфикс воспроизводимого бага (см. также скилл diagnose).
• Часть кода, которую планируем рефакторить — тесты страхуют.

Когда НЕ применять

• UI-компонент, где визуал важнее логики (используй ручную проверку + Playwright позже).
• Прототип / разовый скрипт, который выкинут через час.
• Интеграция с внешним API без чёткого контракта (сначала разведка, потом тесты).
• Простая правка конфига или копи.

Цикл (Red → Green → Refactor)

Шаг 1 — Red (тест падает)

• Назови ожидание словами: «при входе X должно получиться Y».
• Напиши один тест, который проверяет это ожидание. Не пять сразу.
• Запусти тест → должен упасть. Если не упал — тест неверный (что-то проверяет случайно).
• Если тест падает с «module not found» / «is not a function» — это нормально, это «red».

Шаг 2 — Green (минимальная реализация)

• Напиши минимальный код, чтобы тест прошёл.
• Допускается «прибить гвоздями» (захардкодить ответ), если это самое простое.
• Цель этого шага не «красивый код», а «тест зелёный».
• Запусти все тесты — все зелёные.

Шаг 3 — Refactor (улучшаем без потери зелёного)

• Убрать дублирование, дать осмысленные имена, разбить на функции.
• После каждого изменения — прогнать тесты.
• Если тесты красные — откатываемся, переделываем меньшими шагами.

Шаг 4 — Следующий случай

• Добавь следующий тест: edge case, граница, пустой вход, ошибка.
• Снова Red → Green → Refactor.

Какие тесты писать в первую очередь

Порядок приоритета:

1. Happy path — типичный вход → ожидаемый выход.
2. Граничные значения — 0, 1, пустая строка, последний день месяца.
3. Ошибки — неверный тип, отрицательное число, null.
4. Регрессии — для каждого пойманного бага — тест, который его ловит.

Что вернуть пользователю

После цикла — короткий отчёт:

1. Тестов написано: N штук, какие случаи покрывают.
2. Файлы: tests/<...>.test.ts и src/<...>.ts через path:line.
3. Команда запуска: как пользователь сам прогонит локально.
4. Что НЕ покрыто: честно перечисли непокрытые сценарии (не маскируй).

Антипаттерны

• Тест, который проходит даже если код сломан (плохое утверждение).
• Один тест на 50 ассертов — при падении непонятно что сломалось.
• Тестировать имплементацию вместо поведения (привязка к моку приведёт к ложному зелёному в проде).
• «Тесты потом, сначала код» — это не TDD, это «надежда что напишу позже».
• Моки на свою же базу данных в смысло-критичных местах (см. правило о integration tests в .claude/rules).