tdd-red-green-refactor

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

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

3 フェーズのサイクル

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

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

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
};