/tdd

Простым языком

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

Напиши /tdd и опиши задачу — Claude сам напишет проверки, запустит их (они упадут), напишет код (они пройдут) и приберётся. В итоге получаешь код который точно делает то что задумано.

Что делает

/tdd ведёт через полный RED-GREEN-REFACTOR цикл. Сначала пишутся тесты, которые должны падать. Потом — минимальный код для их прохождения. Потом — рефакторинг без потери зелёных тестов. Каждый шаг валидируется автоматическим запуском тест-раннера.

Синтаксис

# TDD для конкретной задачи
/tdd добавить валидацию email при регистрации

# Без аргументов — Claude спросит описание
/tdd

Пошаговый процесс

1. RED: Claude пишет тесты для описанной функциональности — они должны падать
2. Автоматический запуск тестов, проверка что они действительно падают (не из-за синтаксиса)
3. GREEN: минимальный код для прохождения тестов — буквально минимальный
4. Автоматический запуск тестов, все должны пройти
5. REFACTOR: улучшение кода без изменения поведения
6. Финальный запуск — все тесты зелёные, код чище
7. Итерация для следующего сценария или edge-case

Примеры использования

Валидация пользовательского ввода

Нужна функция проверки email. Через TDD сначала описываем все случаи, потом реализуем — уверены что ничего не пропустили.

// RED — тесты написаны первыми:
describe('validateEmail', () => {
  it('принимает корректный email', () => {
    expect(validateEmail('user@example.com')).toBe(true)
  })
  it('отклоняет без @', () => {
    expect(validateEmail('userexample.com')).toBe(false)
  })
  it('отклоняет пустую строку', () => {
    expect(validateEmail('')).toBe(false)
  })
  it('отклоняет null', () => {
    expect(validateEmail(null)).toBe(false)
  })
})

// [Тесты запущены — все падают. GREEN идёт...]

// GREEN — минимальная реализация:
function validateEmail(email: unknown): boolean {
  if (!email || typeof email !== 'string') return false
  return /^[^s@]+@[^s@]+.[^s@]+$/.test(email)
}

Бизнес-логика с edge-cases

TDD особенно ценен для расчётов и бизнес-правил. Тесты описывают ожидания — Claude реализует функцию, которая точно им соответствует.

// Расчёт скидки: сложная логика с условиями
/tdd функция расчёта скидки:
  - 5% при заказе > 1000 руб
  - 10% при заказе > 5000 руб
  - 15% для premium-пользователей (любая сумма)
  - нельзя применять две скидки одновременно

Автоматизация

Автоопределение тест-раннера по конфигам проекта: jest.config.*, vitest.config.*, pytest.ini, pyproject.toml. Не нужно указывать какой инструмент использовать — Claude найдёт сам.

# Поддерживаемые тест-раннеры:
Jest        → jest --watch (TypeScript/JavaScript)
Vitest      → vitest (Vite-проекты)
pytest      → pytest -v (Python)
Go test     → go test ./... (Go)

# /tdd в CI не запускать — только локально

Тесты — не обуза, а навигатор. Они говорят что делать дальше и сигнализируют когда что-то сломалось.