TDD Developer

Red-Green-Refactor サイクルによるテスト駆動開発ガイド。

API不要

スキルパッケージをダウンロード (.skill) GitHubでソースを見る ワークフロー

目次

概要

TDD Developer は、規律あるテスト駆動開発をガイドするスキルです。コードを先に書いてからテストを追加するのではなく、Red-Green-Refactor サイクルに従います。まず失敗するテストを書き、テストを通す最小限のコードを実装し、テストをグリーンに保ったままリファクタリングします。これにより、よりクリーンな設計、高いコード品質、少ない欠陥が実現されます。

pytest, Jest, Vitest, JUnit 5, RSpec, Go testing, xUnit など、複数の言語・テストフレームワークに対応しています。

使用場面

  • 新機能をTDDでゼロから開発したい場合
  • レガシーコードをリファクタリングするために、まずテストカバレッジが必要な場合
  • 正確性が重要な複雑なビジネスロジックを実装する場合
  • ガイド付きの例でTDD手法を学びたい場合
  • テストファーストの開発を明示的に要求する場合

前提条件

  • Claude Code がインストール済みであること
  • tdd-developer スキルが ~/.claude/skills/ にコピー済みであること
  • 言語に対応するテストフレームワークがインストール済みであること(Python なら pytest、JS/TS なら jest など)

外部 API キーやサービスは不要です。

動作の仕組み

Red-Green-Refactor サイクル

各機能は短いサイクルの繰り返しで構築されます:

  1. RED – 小さく焦点を絞ったテストを書き、失敗を確認。構文エラーではなく正しい理由で失敗することを確認。
  2. GREEN – テストを通す最小限のコードを実装。この段階ではハードコードされた値でも可。
  3. REFACTOR – コードを改善(重複排除、命名改善、ロジック簡素化)し、全テストがグリーンのままであることを確認。
  4. COMMIT(任意) – 各サイクル成功後にコミットし、クリーンな履歴を維持。
  RED           GREEN         REFACTOR
 失敗する       テストを       コードを
 テストを  -->  通す最小  -->  改善、
 書く           コード         テスト維持
      \__________________________/
               繰り返し

TDDの三原則

これらの原則がサイクルを規律あるものに保ちます:

  1. 失敗するテストがなければ、プロダクションコードを書いてはならない。 テストが要求しない実装は書かない。
  2. テストは失敗するのに十分なだけ書く。 コンパイルエラーも失敗に数える – テストが失敗した時点で止める。
  3. 現在失敗しているテストを通すのに十分なだけのプロダクションコードを書く。 余分なロジックを追加したい衝動を抑える。

これらの原則に従うと、自然に短いサイクル(各1-2分)になり、すべてのプロダクションコードがテストでカバーされます。

全体ワークフロー

  1. 要件の理解 – 機能を小さくテスト可能な振る舞いに分解し、エッジケースを特定。Claude は「無効な入力の場合はどうすべきですか?」「境界値はありますか?」などの明確化質問を行います。
  2. テストケースの計画 – コードを書く前に、テストケースの優先順位付きリストを作成。エッジケース(空コレクション、null値、境界値)を事前に特定。
  3. サイクルの実行 – 各テストケースに対して Red-Green-Refactor を実行。Claude は毎ステップでテストを実行し、RED/GREEN の状態を確認。
  4. レビュー – すべての振る舞いが実装された後、全体の設計とアーキテクチャを確認。

実装戦略

RED から GREEN への移行時に、Claude は最も適切な戦略を選択します:

Triangulation(三角測量)

正しい実装がすぐに明らかでない場合に使用:

  1. 最初のテストを書き、戻り値をハードコードして通す。
  2. 異なるデータで2番目のテストを追加し、ハードコードされた値を壊す。
  3. 両方のケースを処理するように実装を一般化する。
  4. 一般的なアルゴリズムが浮かび上がるまで例を追加し続ける。

複雑なロジックに対して最も安全な戦略です。具体的な例から段階的にソリューションを構築します。

Fake It Till You Make It(まずは偽装)

素早いフィードバックが欲しい場合に使用:

  1. 最初のテストを即座に通すために定数を返す。
  2. 新しいテストが追加されるにつれ、定数を変数や式に徐々に置き換える。
  3. テストの蓄積が実装を有機的に駆動する。

サイクルを極端に短く保ち、オーバーエンジニアリングを避けます。

Obvious Implementation(明白な実装)

ソリューションが単純明快な場合に使用:

  1. テストを書く。
  2. 実際のロジックを直接実装する(偽装なし)。
  3. テストが予想外に失敗した場合は、より慎重なアプローチとして Triangulation に切り替える。

テストから実装へのマッピングが明確で、エッジケースの可能性が低い場合に選択します。

使い方の例

例1: TDDで機能を構築 

TDDを使ってメールアドレスのバリデーション関数を作成してください。
@の欠如、ドメインの欠如、空文字、null値に対応してください。

テストケースの計画後、各 Red-Green-Refactor サイクルを順に実行し、毎ステップでテストを実行します。

例2: 既存コードにテストカバレッジを追加 

この PriceCalculator クラスにTDDスタイルのテストを追加し、
テストしやすいようにリファクタリングしてください。

まず既存の振る舞いに対するテストを書き、テストをグリーンに保ちながらリファクタリングを支援します。

例3: 特定フレームワークでのTDD 

pytest を使ったTDDでショッピングカートモジュールを実装してください。
商品追加、数量管理、割引ロジックの順で進めてください。

指定されたフレームワークを使用し、テストサイクルを通じて段階的に機能を構築します。

例4: バグ再現のためのTDD 

ユーザーが送信ボタンをダブルクリックすると重複注文が
作成されるバグがあります。まず再現する失敗テストを書いてから修正してください。

Claude が競合状態を示すテストを書き、失敗を確認した後、テストをグリーンに保ちながら修正を実装します。

トラブルシューティング

テストは通るが Refactor ステップが省略される

症状: Claude がテスト(RED)を書き、通す(GREEN)と、リファクタリングせずに次のテストに進んでしまう。

解決策: 「次に進む前にリファクタリングしてください」と明示的に伝えるか、「厳密な Red-Green-Refactor に従ってください」と指示してください。現在の実装と以前のコードの間に重複がないか確認するよう促すことも有効です。

サイクルが大きすぎて時間がかかる

症状: 1つの Red-Green-Refactor サイクルが多数のファイルにまたがり、数分以上かかる。

解決策: 振る舞いをより小さな単位に分割してください。「認証フロー全体を実装」ではなく、「ユーザー名が空でないことを検証」から始めます。各サイクルは1つの小さく焦点を絞ったテストに対応すべきです。GREEN ステップで数行以上のコードが必要な場合、テストが大きすぎる可能性があります。

テストフレームワークが正しく検出されない

症状: Claude が間違ったフレームワークや構文でテストを書く(例: pytest ではなく unittest を使用)。

解決策: プロンプトでフレームワークを明示してください: 「pytest を使ってTDDで」または「Jest でTDDを」。プロジェクトに既存のテストスイートがある場合は、既存のテストファイルを Claude に示して規約に合わせることができます。

ヒントとベストプラクティス

  • サイクルを短く保つ – 1つの Red-Green-Refactor サイクルは1-2分を目安に。それ以上かかる場合は、テストをより小さな振る舞いに分割してください。
  • 実装ではなく振る舞いをテストする – 出力と副作用に対してアサートし、内部構造はテストしない。リファクタリングに強いテストになります。
  • Arrange-Act-Assert パターンを使う – セットアップ、実行、検証を明確に分けてテストを構成。
  • リファクタリングを省略しない – Refactor ステップは設計改善が起こる場所。省略すると技術的負債が蓄積されます。
  • モックを使いすぎない – 過度なモックはテストを脆く、実装に密結合にします。
  • パラメータ化テストを活用 – 異なる入力値で同様のテストケースを効率的にカバー。

よくある落とし穴

落とし穴 問題点
コードの後にテストを書く TDDの設計上のメリットが失われる
100%カバレッジを追求 意味のあるカバレッジに集中すべき
実装の詳細をテストする リファクタリング時にテストが壊れる
大きなテストを書く 失敗箇所の特定が困難
Refactorステップを省略 技術的負債が蓄積される

関連スキル