Рабочий процесс TDD: полный цикл Red-Green-Refactor от /plan до /verify

Чему вы научитесь

Использовать команду /plan для создания систематического плана реализации и предотвращения упущений
Применять команду /tdd для разработки через тестирование по циклу RED-GREEN-REFACTOR
Обеспечивать безопасность и качество кода с помощью /code-review
Проверять готовность кода к коммиту с помощью /verify
Достигать 80%+ покрытия тестами и создавать надёжный набор тестов

Знакомые проблемы

Сталкивались ли вы с такими ситуациями при разработке новых функций:

Написали код и обнаружили, что неправильно поняли требования — приходится переделывать
Низкое покрытие тестами, баги обнаруживаются после релиза
На код-ревью находят проблемы безопасности — код возвращают на доработку
После коммита выясняется, что есть ошибки типов или сборка падает
Непонятно, когда писать тесты, тесты получаются неполными

Все эти проблемы снижают эффективность разработки и затрудняют обеспечение качества кода.

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

Сценарии использования рабочего процесса TDD:

Разработка новых функций: от требований до реализации — гарантия полноты функционала и достаточного тестового покрытия
Исправление багов: сначала пишем тест для воспроизведения бага, затем исправляем — уверенность, что не появятся новые проблемы
Рефакторинг кода: с защитой тестами можно спокойно оптимизировать структуру кода
Реализация API-эндпоинтов: интеграционные тесты проверяют корректность интерфейсов
Разработка критичной бизнес-логики: финансовые расчёты, аутентификация и другой важный код требуют 100% покрытия тестами

Ключевой принцип

Разработка через тестирование — это не просто процесс «сначала пишем тесты». Это системный метод обеспечения качества кода и повышения эффективности разработки. Весь новый код должен создаваться через TDD-процесс.

Основная идея

Рабочий процесс TDD состоит из 4 ключевых команд, образующих полный цикл разработки:

1. /plan     → Планирование: уточнение требований, выявление рисков, поэтапная реализация
2. /tdd      → Реализация: сначала тесты, минимальный код, непрерывный рефакторинг
3. /code-review → Ревью: проверка безопасности, оценка качества, лучшие практики
4. /verify   → Верификация: сборка, типы, тесты, аудит кода

Почему этот процесс работает:

Планирование в начале: /plan обеспечивает правильное понимание, предотвращает ошибки направления
Тесты в приоритете: /tdd принуждает писать тесты первыми, гарантирует тестовое покрытие каждой функции
Контроль на ревью: /code-review выявляет уязвимости безопасности и проблемы качества кода
Верификация в конце: /verify гарантирует безопасность коммита

🎒 Подготовка перед началом

Перед началом работы с TDD-процессом убедитесь:

✅ Установлен плагин Everything Claude Code
✅ В проекте настроен тестовый фреймворк (Jest, Vitest и т.д.)
✅ В проекте есть базовый процесс сборки (npm run build)
✅ Вы изучили базовое использование команд в Быстром старте

Предварительные требования

Это руководство предполагает, что вы уже знакомы с базовыми операциями из Быстрого старта. Если установка ещё не выполнена, сначала прочитайте Руководство по установке.

Практика: полный рабочий процесс TDD

Давайте изучим весь процесс на практическом примере. Предположим, вам нужно реализовать функцию «Калькулятор оценки ликвидности рынка».

Шаг 1: Создание плана реализации с помощью /plan

Зачем Этап планирования гарантирует понимание требований, выявление потенциальных рисков и предотвращение переделок в будущем.

Действие Введите в Claude Code:

/plan Мне нужно реализовать калькулятор оценки ликвидности рынка, который рассчитывает оценку (0-100) на основе объёма торгов, спреда bid-ask, количества активных трейдеров и времени последней сделки

Ожидаемый результат Агент planner сгенерирует детальный план реализации:

markdown

## Implementation Plan: Калькулятор оценки ликвидности рынка

## Requirements Restatement
- Рассчитать оценку ликвидности рынка (0-100) на основе нескольких показателей
- Чем выше оценка, тем лучше ликвидность рынка
- Учитываются: объём торгов, спред bid-ask, активные трейдеры, время последней сделки

## Implementation Phases

### Phase 1: Define Interface
- Создать интерфейс `MarketData` для определения входных данных
- Определить сигнатуру функции `calculateLiquidityScore`

### Phase 2: Write Tests
- Написать юнит-тесты для различных сценариев
- Граничные условия: нулевой объём, экстремальные значения
- Обработка ошибок: отсутствующие поля, неверные типы

### Phase 3: Implement Calculation
- Реализовать алгоритм расчёта оценки
- Взвешенный расчёт по каждому показателю
- Нормализация в диапазон 0-100

### Phase 4: Integration
- Интеграция в существующий API
- Добавление эндпоинта для доступа к функции расчёта
- Документирование использования

## Dependencies
- Внешние зависимости отсутствуют

## Risks
- MEDIUM: Возможно потребуется корректировка весов алгоритма оценки
- LOW: Обработка граничных условий

**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)

Контрольная точка ✅

Убедитесь, что требования поняты правильно
Убедитесь, что шаги реализации разумны
Проверьте, нет ли упущенных рисков

Следующий шаг Если план в порядке, ответьте yes или proceed. Если нужны изменения — укажите конкретные правки.

Шаг 2: Выполнение разработки через тестирование с помощью /tdd

Зачем Команда /tdd принуждает писать тесты первыми, гарантирует тестовое покрытие каждой функции и избавляет от боли дописывания тестов позже.

Действие После подтверждения плана введите:

/tdd Реализовать калькулятор оценки ликвидности рынка согласно плану

Ожидаемый результат Агент tdd-guide проведёт вас через TDD-процесс:

Фаза RED: Сначала пишем тесты

typescript

// lib/liquidity.ts
export interface MarketData {
  totalVolume: number
  bidAskSpread: number
  activeTraders: number
  lastTradeTime: Date
}

export function calculateLiquidityScore(market: MarketData): number {
  // TODO: Implementation
  throw new Error('Not implemented')
}

typescript

// lib/liquidity.test.ts
import { calculateLiquidityScore } from './liquidity'

describe('calculateLiquidityScore', () => {
  it('should return high score for liquid market', () => {
    const market = {
      totalVolume: 100000,
      bidAskSpread: 0.01,
      activeTraders: 500,
      lastTradeTime: new Date()
    }

    const score = calculateLiquidityScore(market)

    expect(score).toBeGreaterThan(80)
    expect(score).toBeLessThanOrEqual(100)
  })

  it('should return low score for illiquid market', () => {
    const market = {
      totalVolume: 100,
      bidAskSpread: 0.5,
      activeTraders: 2,
      lastTradeTime: new Date(Date.now() - 86400000) // 1 день назад
    }

    const score = calculateLiquidityScore(market)

    expect(score).toBeLessThan(30)
    expect(score).toBeGreaterThanOrEqual(0)
  })

  it('should handle edge case: zero volume', () => {
    const market = {
      totalVolume: 0,
      bidAskSpread: 0,
      activeTraders: 0,
      lastTradeTime: new Date()
    }

    const score = calculateLiquidityScore(market)

    expect(score).toBe(0)
  })
})

bash

npm test lib/liquidity.test.ts

## Вы должны увидеть падение тестов
FAIL lib/liquidity.test.ts
  ✕ should return high score for liquid market
    Error: Not implemented

✅ Тесты упали — это ожидаемо

Фаза GREEN: Реализуем минимальный код

typescript

export function calculateLiquidityScore(market: MarketData): number {
  // Handle zero volume edge case
  if (market.totalVolume === 0) {
    return 0
  }

  // Calculate component scores (0-100 scale)
  const volumeScore = Math.min(market.totalVolume / 1000, 100)
  const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
  const traderScore = Math.min(market.activeTraders / 10, 100)

  // Recent activity bonus
  const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
  const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)

  // Weighted average
  const score = (
    volumeScore * 0.4 +
    spreadScore * 0.3 +
    traderScore * 0.2 +
    recencyScore * 0.1
  )

  return Math.min(Math.max(score, 0), 100) // Clamp to 0-100
}

bash

npm test lib/liquidity.test.ts

## Вы должны увидеть прохождение тестов
PASS lib/liquidity.test.ts
  ✓ should return high score for liquid market (3 ms)
  ✓ should return low score for illiquid market (2 ms)
  ✓ should handle edge case: zero volume (1 ms)

3 tests passed

✅ Все тесты прошли

Фаза REFACTOR: Улучшаем код

typescript

// lib/liquidity.ts - после рефакторинга
const WEIGHTS = {
  VOLUME: 0.4,
  SPREAD: 0.3,
  TRADERS: 0.2,
  RECENCY: 0.1,
} as const

const SCALE_FACTORS = {
  VOLUME: 1000,
  SPREAD: 1000,
  TRADERS: 10,
  RECENCY_PENALTY: 10,
} as const

function clamp(value: number, min: number, max: number): number {
  return Math.min(Math.max(value, min), max)
}

export function calculateLiquidityScore(market: MarketData): number {
  if (market.totalVolume === 0) return 0

  const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
  const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
  const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)

  const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
  const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)

  const weightedScore =
    volumeScore * WEIGHTS.VOLUME +
    spreadScore * WEIGHTS.SPREAD +
    traderScore * WEIGHTS.TRADERS +
    recencyScore * WEIGHTS.RECENCY

  return clamp(weightedScore, 0, 100)
}

bash

npm test lib/liquidity.test.ts

## Вы должны увидеть, что тесты по-прежнему проходят
PASS lib/liquidity.test.ts
  ✓ should return high score for liquid market (3 ms)
  ✓ should return low score for illiquid market (2 ms)
  ✓ should handle edge case: zero volume (1 ms)

3 tests passed

✅ Рефакторинг завершён, тесты по-прежнему проходят

Проверка покрытия

bash

npm test -- --coverage lib/liquidity.test.ts

File           | % Stmts | % Branch | % Funcs | % Lines
---------------|---------|----------|---------|--------
liquidity.ts   |   100   |   100    |   100   |   100

Coverage: 100% ✅ (Target: 80%)

✅ TDD-процесс завершён, покрытие соответствует требованиям

Контрольная точка ✅

Тесты написаны до кода (RED)
Реализация после падения тестов (GREEN)
Рефакторинг после прохождения тестов (REFACTOR)
Покрытие выше 80%

Шаг 3: Ревью кода с помощью /code-review

Зачем Код-ревью позволяет обнаружить проблемы безопасности, качества кода и соответствия лучшим практикам, гарантируя безопасность мержа.

Действие Введите:

/code-review

Ожидаемый результат Агент code-reviewer проверит:

markdown

## Code Review Report

## Security Issues (CRITICAL)
- ✅ No hardcoded credentials found
- ✅ No SQL injection vulnerabilities
- ✅ No XSS vulnerabilities

## Code Quality (HIGH)
- ✅ Functions under 50 lines (current: 8 lines max)
- ✅ Files under 800 lines (current: 25 lines)
- ✅ No missing error handling
- ⚠️ Found 1 console.log statement at lib/liquidity.ts:15
  - **Suggestion**: Remove or replace with proper logging

## Best Practices (MEDIUM)
- ✅ Using immutable patterns
- ✅ No TODO/FIXME comments
- ✅ All new code has tests
- ✅ JSDoc for public API present

## Summary
- Critical: 0 issues
- High: 1 issue (console.log)
- Medium: 0 issues

**Recommendation**: Fix console.log issue, then ready for commit.

Следующий шаг Исправьте проблемы по результатам ревью:

typescript

// Удаляем console.log
// console.log(`Calculated score: ${score}`)  // удалено
return clamp(weightedScore, 0, 100)

Контрольная точка ✅

Исправлены все проблемы уровня CRITICAL
Исправлены или обоснованы проблемы уровня HIGH
Проверено соответствие стандартам качества кода

Шаг 4: Верификация кода с помощью /verify

Зачем Команда верификации гарантирует безопасность коммита: сборка, типы, тесты проходят, нет оставшихся проблем.

Действие Введите:

/verify

Ожидаемый результат Полный отчёт верификации:

markdown

VERIFICATION: PASS

Build:    OK
Types:    OK (0 errors)
Lint:     OK (0 issues)
Tests:    3/3 passed, 100% coverage
Secrets:  OK (0 found)
Logs:      OK (0 console.logs)

Ready for PR: YES ✅

Если есть проблемы, они будут детально перечислены:

markdown

VERIFICATION: FAIL

Build:    OK
Types:    ❌ 2 errors
  - lib/liquidity.ts:15:25 - Type 'string' is not assignable to type 'number'
  - lib/utils.ts:8:10 - Property 'toFixed' does not exist on type 'unknown'
Lint:     ⚠️ 2 warnings
  - lib/liquidity.ts:10:1 - Missing JSDoc for WEIGHTS constant
Tests:    ✅ 3/3 passed, 100% coverage
Secrets:  OK
Logs:      OK

Ready for PR: NO ❌

Fix these issues before committing.

Контрольная точка ✅

Сборка проходит
Проверка типов проходит
Lint проходит (или только предупреждения)
Все тесты проходят
Покрытие 80%+
Нет console.log
Нет захардкоженных секретов

Шаг 5: Коммит кода

Зачем После прохождения верификации код готов к коммиту и может быть безопасно отправлен в удалённый репозиторий.

Действие

bash

git add lib/liquidity.ts lib/liquidity.test.ts
git commit -m "feat: add market liquidity score calculator

- Calculate 0-100 score based on volume, spread, traders, recency
- 100% test coverage with unit tests
- Edge cases handled (zero volume, illiquid markets)
- Refactored with constants and helper functions

Closes #123"

bash

git push origin feature/liquidity-score

Типичные ошибки

Ошибка 1: Пропуск фазы RED и написание кода сразу

Неправильный подход:

Сначала реализовать функцию calculateLiquidityScore
Потом написать тесты

Последствия:

Тесты могут лишь «подтверждать существующую реализацию», а не проверять поведение
Легко упустить граничные случаи и обработку ошибок
При рефакторинге нет уверенности в безопасности изменений

Правильный подход:

1. Сначала написать тесты (они должны падать)
2. Запустить тесты и убедиться в падении (RED)
3. Реализовать код для прохождения тестов (GREEN)
4. Рефакторить, сохраняя прохождение тестов (REFACTOR)

Ошибка 2: Недостаточное покрытие тестами

Неправильный подход:

Написать только один тест, покрытие всего 40%

Последствия:

Большая часть кода без тестовой защиты
При рефакторинге легко внести баги
Код вернут на доработку при ревью

Правильный подход:

Обеспечить 80%+ покрытие:
- Юнит-тесты: покрыть все функции и ветвления
- Интеграционные тесты: покрыть API-эндпоинты
- E2E-тесты: покрыть критичные пользовательские сценарии

Ошибка 3: Игнорирование рекомендаций code-review

Неправильный подход:

Увидеть проблему CRITICAL и всё равно закоммитить

Последствия:

Уязвимости безопасности попадают в продакшен
Низкое качество кода, сложность поддержки
PR отклоняют ревьюеры

Правильный подход:

- Проблемы CRITICAL — обязательно исправить
- Проблемы HIGH — по возможности исправить или обосновать
- Проблемы MEDIUM/LOW — можно оптимизировать позже

Ошибка 4: Коммит без запуска /verify

Неправильный подход:

Написать код и сразу git commit, пропустив верификацию

Последствия:

Падение сборки, трата ресурсов CI
Ошибки типов приводят к runtime-ошибкам
Тесты не проходят, нестабильное состояние основной ветки

Правильный подход:

Всегда запускать /verify перед коммитом:
/verify
# Коммитить только при "Ready for PR: YES"

Ошибка 5: Тестирование деталей реализации вместо поведения

Неправильный подход:

typescript

// Тестирование внутреннего состояния
expect(component.state.count).toBe(5)

Последствия:

Хрупкие тесты, массовые падения при рефакторинге
Тесты не отражают то, что видит пользователь

Правильный подход:

typescript

// Тестирование видимого пользователю поведения
expect(screen.getByText('Count: 5')).toBeInTheDocument()

Итоги урока

Ключевые моменты рабочего процесса TDD:

Планирование в начале: используйте /plan для правильного понимания и предотвращения ошибок направления
Тесты в приоритете: используйте /tdd для принудительного написания тестов первыми по циклу RED-GREEN-REFACTOR
Код-ревью: используйте /code-review для выявления проблем безопасности и качества
Полная верификация: используйте /verify для гарантии безопасности коммита
Требования к покрытию: обеспечьте 80%+ покрытие тестами, 100% для критичного кода

Эти четыре команды образуют полный цикл разработки, обеспечивающий качество кода и эффективность разработки.

Запомните этот процесс

Требования → /plan → /tdd → /code-review → /verify → Коммит

Каждая новая функция должна следовать этому процессу.

Анонс следующего урока

В следующем уроке мы изучим Процесс код-ревью: /code-review и аудит безопасности.
Вы узнаете:
Глубокое понимание логики проверок агента code-reviewer
Чек-лист аудита безопасности
Как исправлять типичные уязвимости безопасности
Как настраивать пользовательские правила ревью

Приложение: Справочник по исходному коду

Нажмите, чтобы увидеть расположение исходного кода

Дата обновления: 2026-01-25

Функция	Путь к файлу	Строки
Команда /plan	`commands/plan.md`	1-114
Команда /tdd	`commands/tdd.md`	1-327
Команда /verify	`commands/verify.md`	1-60
---	---	---
---	---	---
---	---	---

Ключевые функции:

plan вызывает агент planner для создания плана реализации
tdd вызывает агент tdd-guide для выполнения процесса RED-GREEN-REFACTOR
verify выполняет полную проверку (сборка, типы, lint, тесты)
code-review проверяет уязвимости безопасности, качество кода, лучшие практики

Требования к покрытию:

Минимум 80% покрытия кода (branches, functions, lines, statements)
Финансовые расчёты, логика аутентификации, критичный для безопасности код требуют 100% покрытия

Рабочий процесс TDD: полный цикл Red-Green-Refactor от /plan до /verify ​

Чему вы научитесь ​

Знакомые проблемы ​

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

Основная идея ​

🎒 Подготовка перед началом ​

Практика: полный рабочий процесс TDD ​

Шаг 1: Создание плана реализации с помощью /plan ​

Шаг 2: Выполнение разработки через тестирование с помощью /tdd ​

Фаза RED: Сначала пишем тесты ​

Фаза GREEN: Реализуем минимальный код ​

Фаза REFACTOR: Улучшаем код ​

Проверка покрытия ​

Шаг 3: Ревью кода с помощью /code-review ​

Шаг 4: Верификация кода с помощью /verify ​

Шаг 5: Коммит кода ​

Типичные ошибки ​

Ошибка 1: Пропуск фазы RED и написание кода сразу ​

Ошибка 2: Недостаточное покрытие тестами ​

Ошибка 3: Игнорирование рекомендаций code-review ​

Ошибка 4: Коммит без запуска /verify ​

Ошибка 5: Тестирование деталей реализации вместо поведения ​

Итоги урока ​

Анонс следующего урока ​

Приложение: Справочник по исходному коду ​

Рабочий процесс TDD: полный цикл Red-Green-Refactor от /plan до /verify

Чему вы научитесь

Знакомые проблемы

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

Основная идея

🎒 Подготовка перед началом

Практика: полный рабочий процесс TDD

Шаг 1: Создание плана реализации с помощью /plan

Шаг 2: Выполнение разработки через тестирование с помощью /tdd

Фаза RED: Сначала пишем тесты

Фаза GREEN: Реализуем минимальный код

Фаза REFACTOR: Улучшаем код

Проверка покрытия

Шаг 3: Ревью кода с помощью /code-review

Шаг 4: Верификация кода с помощью /verify

Шаг 5: Коммит кода

Типичные ошибки

Ошибка 1: Пропуск фазы RED и написание кода сразу

Ошибка 2: Недостаточное покрытие тестами

Ошибка 3: Игнорирование рекомендаций code-review

Ошибка 4: Коммит без запуска /verify

Ошибка 5: Тестирование деталей реализации вместо поведения

Итоги урока

Анонс следующего урока

Приложение: Справочник по исходному коду