tdd-red-green-refactor

Red-Green-Refactor（TDD）スキル：TypeScript 版

このスキルは、AI 支援プログラミングのための構造的なフレームワークを導入し、すべてのコード行が検証可能で、型付けされ、目的を持つことを保証します。

3 段階のサイクル

フェーズ 1：Red（失敗を確認）

機能が存在しないことと、テストが有効であることを証明する必要があります。

1. テストを 1 つ書く：次に実装する小さな振る舞いに対するテストケースを 1 つ作成します（例：Vitest または Jest を使用）。
2. 実行して失敗させる：テストを実行します。必ず失敗しなければなりません。
3. 検証する：失敗の原因が設定エラーではなく、ロジックの不足（例：ReferenceError: add is not defined）にあることを確認します。

フェーズ 2：Green（最小限の合格）

できるだけ早く、簡潔にテストを合格させます。

1. 最小限の実装：テストを満たす最もシンプルなコードを書きます。将来に備えた実装はせず、現在の「Red」テストだけに厳密に集中します。
2. テストを実行する：テストスイートを実行します。すべてのテストが Green でなければなりません。
3. 証拠：Red から Green への移行が、開発者の「作業の証明」です。

フェーズ 3：Refactor（整理）

「Green」の状態を維持しながら、コードの構造を改善します。

1. 整理する：フェーズ 2 で書いたコードの命名を改善し、重複を取り除き、最適化します。
2. セーフティネット：変更のたびにテストを再実行します。Red になった場合は、直ちに変更を元に戻します。

---

基本的な運用ルール

1.「水平的な一括実装」をしない

複数のテストを一度に大量に書くことは固く禁じられています。次のように、厳密に段階的なサイクルに従う必要があります。

• テストを 1 つ書く -> 失敗を確認する -> 修正を 1 つ書く -> 合格を確認する。
• サブ機能ごとにこのサイクルを繰り返します。

2. バックプレッシャーをかける

自動アサーションと強い型付け（TypeScript）をバックプレッシャーとして使用し、AI が解決策を「推測」したり、低品質なコードで「泥遊び」したりするのを防ぎます。

3. 整合性を検証する

実装の失敗を通すために、既存のテストを変更してはいけません。テストを変更する必要があるのは、要件が変わった場合であり、コードを書くのが難しいからではありません。

---

ワークフローの例（TypeScript + Vitest）

ステップ 1：Red

// math.test.ts
import { describe, it, expect } from 'vitest';
import { add } from './math';

describe('add', () => {
  it('should sum two numbers', () => {
    expect(add(2, 2)).toBe(4); // Fails: ReferenceError: add is not defined
  });
});

ステップ 2：Green

// math.ts
export const add = (a: any, b: any) => {
  return 4; // Passes: Minimal code to satisfy the test
};

ステップ 3：Refactor

// math.ts
/**
 * Sums two numbers with explicit type safety.
 */
export const add = (a: number, b: number): number => {
  return a + b; // Passes: Proper implementation with safety net
};