Цикл Red-Green-Refactor и ментальная модель TDD

Архитектурная база#

В традиционном подходе к разработке программного обеспечения тесты пишутся постфактум — после реализации бизнес-логики. Это создает фундаментальную архитектурную проблему: инженер пишет тесты, подстраиваясь под уже созданную внутреннюю структуру классов, замыканий и структур данных. В результате тесты оказываются жестко сцепленными с деталями реализации (High Coupling to Implementation Details), а проектирование публичного интерфейса (Public API) происходит с точки зрения поставщика сервиса, а не его потребителя.

Test-Driven Development (TDD) переворачивает этот процесс. Написание падающего теста вынуждает разработчика в первую очередь ответить на вопросы взаимодействия:

• Какую сигнатуру должен иметь публичный метод?
• Какие входные параметры минимально необходимы для выполнения контракта?
• Какую структуру данных удобнее всего получать потребителю в качестве результата?
• Как изолировать побочные эффекты и сделать зависимость инжектируемой?

TDD служит дисциплиной декомпозиции: сложная бизнес-задача разбивается на серию дискретных, детерминированных спецификаций. Это устраняет спекулятивную функциональность (YAGNI — You Aren't Gonna Need It) и предотвращает разрастание когнитивной нагрузки.

Три закона TDD Роберта Мартина#

Формализация процесса TDD опирается на три закона:

1. Первый закон: Не разрешается писать продакшен-код, пока не написан падающий модульный тест. Невозможность компиляции или ошибка линтера также считается падением.
2. Второй закон: Не разрешается писать тест в объеме большем, чем требуется для фиксации ошибки/падения.
3. Третий закон: Не разрешается писать продакшен-код в объеме большем, чем строго необходимо для прохождения текущего падающего теста.

Соблюдение этих правил формирует жесткий, непрерывный микроцикл: шаг написания теста длится от нескольких секунд до 1-2 минут, за которым следует минимальная правка кода и запуск тестового раннера.

Ментальная модель#

Внутреннее устройство TDD описывается классическим замкнутым конвейером Red-Green-Refactor.

Каждая фаза цикла имеет строго очерченные границы ответственности:

+-----------------------------------------------------------------------+
|                              TDD CYCLE                                |
+-----------------------------------------------------------------------+
|                                                                       |
|   +-------------------+       +--------------------+                  |
|   | 1. RED            | ----> | 2. GREEN           |                  |
|   | Написание         |       | Минимальный код    |                  |
|   | падающего теста   |       | для прохождения    |                  |
|   +-------------------+       +--------------------+                  |
|             ^                           |                             |
|             |                           v                             |
|      Новое  |                 +--------------------+                  |
|      требо- |                 | 3. REFACTOR        |                  |
|      вание  +---------------- | Устранение запахов |                  |
|                               | (тесты зеленые)    |                  |
|                               +--------------------+                  |
|                                                                       |
+-----------------------------------------------------------------------+

Фаза RED: Проектирование контракта#

На фазе Red пишется спецификация на еще не существующий функционал. Главное правило: тест обязан упасть по ожидаемой причине.

• Если тест упал с ошибкой ReferenceError: calculateDiscount is not defined или ошибкой сборки TypeScript — требование зафиксировано, контракт определен.
• Если тест упал из-за несовпадения ассерта (AssertionError: expected undefined to be 42) — подтверждено отсутствие функциональности.
• Если тест внезапно стал зеленым без изменения продакшен-кода — тест тавтологичен, либо функционал уже существует. Такой тест бесполезен.

Фаза GREEN: Принцип наименьшего сопротивления#

Цель фазы Green — максимально быстро вернуть тестовый сьют в рабочее состояние (Exit from Red state). Разрешается применять стратегии:

1. Fake It (Фальсификация): Возврат константы (Hardcoded value), удовлетворяющей текущий ассерт.
2. Triangulation (Триангуляция): Добавление второго теста с иными аргументами, вынуждающее параметризовать константу в алгоритм.
3. Obvious Implementation (Очевидная реализация): Прямое написание тривиального алгоритма, если решение очевидно и не требует постепенного вывода.

Фаза REFACTOR: Архитектурная реструктуризация#

Только когда все тесты зеленые, разработчик получает право изменять исходный код без страха сломать существующие контракты. Фаза Refactor нацелена на:

• Устранение дублирования логики (DRY).
• Выделение приватных вспомогательных функций и чистых трансформаций.
• Оптимизацию алгоритмической сложности без изменения внешнего поведения.
• Улучшение читаемости имен переменных и типизации.

На практике применяется#

1. Разработка алгоритмов аутентификации и авторизации: Проектирование парсеров токенов, валидаторов цифровых подписей и вычислителей разрешений (RBAC/ABAC) с гарантией обработки граничных условий (просроченные токены, искаженные заголовки).
2. Финансовые и биллинговые калькуляторы: Расчет прогрессивных налоговых шкал, курсовых разниц и конвертации валют, где любая погрешность в округлении критична.
3. Парсеры доменных языков и AST-трансформации: Построение компиляторов математических выражений, markdown-парсеров и сериализаторов протоколов шаг за шагом от простых токенов к сложным узлам деревьев.
4. Сложные машины состояний (FSM): Пошаговая реализация переходов состояний распределенных транзакций или процессов оформления заказов.

Как это работает#

Рассмотрим реализацию сервиса валидации и декодирования токенов доступа с ограниченными правами (Scope Evaluator) с применением строгой техники TDD и раннера Vitest.

Шаг 1: Фаза RED — Первая спецификация#

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

import { describe, it, expect } from 'vitest';
import { ScopeEvaluator, SecurityTokenError } from './scope-evaluator';

describe('ScopeEvaluator', () => {
  it('должен выбрасывать SecurityTokenError при передаче пустой строки', () => {
    const evaluator = new ScopeEvaluator();

    expect(() => evaluator.evaluateToken('', ['read:users'])).toThrow(
      SecurityTokenError
    );
  });
});

Запуск Vitest завершается ошибкой сборки TypeScript: модуль ./scope-evaluator не найден. Фаза RED пройдена — падение по понятной причине.

Шаг 2: Фаза GREEN — Минимальная реализация#

Создаем минимально достаточный код для прохождения первого теста.

export class SecurityTokenError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'SecurityTokenError';
  }
}

export class ScopeEvaluator {
  evaluateToken(token: string, requiredScopes: readonly string[]): boolean {
    if (!token) {
      throw new SecurityTokenError('Token cannot be empty');
    }
    return false;
  }
}

Тест проходит успешно (PASS). Все тесты зеленые.

Шаг 3: Фаза RED — Добавление требования проверки формата и прав#

Добавляем спецификацию: токен состоит из префикса Bearer , полезной нагрузки в формате Base64 и набора скоупов, разделенных двоеточием.

it('должен возвращать true, если токен содержит все требуемые скоупы', () => {
  const evaluator = new ScopeEvaluator();
  // Закодированная полезная нагрузка: {"sub":"usr_123","scopes":["read:users","write:orders"]}
  const payload = Buffer.from(
    JSON.stringify({
      sub: 'usr_123',
      scopes: ['read:users', 'write:orders'],
    })
  ).toString('base64url');

  const rawToken = `Bearer ${payload}`;

  const hasAccess = evaluator.evaluateToken(rawToken, ['read:users']);
  expect(hasAccess).toBe(true);
});

it('должен возвращать false, если токен не содержит хотя бы один обязательный скоуп', () => {
  const evaluator = new ScopeEvaluator();
  const payload = Buffer.from(
    JSON.stringify({
      sub: 'usr_123',
      scopes: ['read:users'],
    })
  ).toString('base64url');

  const rawToken = `Bearer ${payload}`;

  const hasAccess = evaluator.evaluateToken(rawToken, ['read:users', 'admin:all']);
  expect(hasAccess).toBe(false);
});

Тесты падают (FAIL), так как метод evaluateToken всегда возвращает false.

Шаг 4: Фаза GREEN — Расширение реализации#

Пишем рабочий код для парсинга Base64-пейлоада и сопоставления скоупов.

interface TokenPayload {
  readonly sub: string;
  readonly scopes: readonly string[];
}

export class ScopeEvaluator {
  evaluateToken(token: string, requiredScopes: readonly string[]): boolean {
    if (!token || !token.trim()) {
      throw new SecurityTokenError('Token cannot be empty');
    }

    if (!token.startsWith('Bearer ')) {
      throw new SecurityTokenError('Invalid authorization scheme');
    }

    const base64Payload = token.slice(7);
    let parsed: TokenPayload;

    try {
      const decodedJson = Buffer.from(base64Payload, 'base64url').toString('utf-8');
      parsed = JSON.parse(decodedJson) as TokenPayload;
    } catch {
      throw new SecurityTokenError('Malformed token payload');
    }

    if (!Array.isArray(parsed.scopes)) {
      return false;
    }

    const tokenScopeSet = new Set(parsed.scopes);
    return requiredScopes.every((scope) => tokenScopeSet.has(scope));
  }
}

Все 3 теста зеленые (PASS). Переходим к следующей фазе.

Шаг 5: Фаза REFACTOR — Очистка и разделение ответственности#

Класс ScopeEvaluator нарушает принцип единой ответственности (SRP): он и парсит сырую строку токена, и валидирует схему Bearer, и декодирует Base64, и вычисляет подмножество прав. Проведем рефакторинг, выделив чистый токенайзер, не сломав ни одного теста.

export class SecurityTokenError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'SecurityTokenError';
  }
}

export interface DecodedToken {
  readonly subject: string;
  readonly scopes: ReadonlySet<string>;
}

export class TokenParser {
  private static readonly BEARER_PREFIX = 'Bearer ';

  public static parse(rawToken: string): DecodedToken {
    if (!rawToken || !rawToken.trim()) {
      throw new SecurityTokenError('Token cannot be empty');
    }

    if (!rawToken.startsWith(this.BEARER_PREFIX)) {
      throw new SecurityTokenError('Invalid authorization scheme');
    }

    const base64Payload = rawToken.slice(this.BEARER_PREFIX.length);
    
    try {
      const json = Buffer.from(base64Payload, 'base64url').toString('utf-8');
      const payload = JSON.parse(json) as { sub?: unknown; scopes?: unknown };

      if (typeof payload.sub !== 'string' || !Array.isArray(payload.scopes)) {
        throw new Error('Invalid token structure');
      }

      return {
        subject: payload.sub,
        scopes: new Set(payload.scopes.filter((s): s is string => typeof s === 'string')),
      };
    } catch (error) {
      if (error instanceof SecurityTokenError) throw error;
      throw new SecurityTokenError('Malformed token payload');
    }
  }
}

export class ScopeEvaluator {
  public evaluateToken(token: string, requiredScopes: readonly string[]): boolean {
    const decoded = TokenParser.parse(token);
    return this.hasRequiredScopes(decoded.scopes, requiredScopes);
  }

  private hasRequiredScopes(
    grantedScopes: ReadonlySet<string>,
    requiredScopes: readonly string[]
  ): boolean {
    return requiredScopes.every((scope) => grantedScopes.has(scope));
  }
}

Запуск Vitest подтверждает: 100% тестов остаются зелеными, но внутренняя структура системы стала модульной, строго типизированной и готовой к расширению.

Распространённые ошибки#

Вопросы для собеседования#

Связанные темы#