Цикл 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% тестів залишаються зеленими, а внутрішня структура стала модульною, суворо типізованою і готовою до розширення.

Поширені помилки#

Покроковий алгоритм циклу Red-Green-Refactor#

Питання для співбесіди#

Пов'язані теми#