test-driven-development

概要

このスキルでできること

test-driven-development スキルは、厳格な Test-Driven Development (TDD) ワークフローをルールとして定義します。必ず本番コードより先に失敗するテストを書き、その上でストイックに Red-Green-Refactor サイクルを回していきます。

「そのうちテストも書く」という緩い方針ではなく、このスキルは次のような強いルールを課します。

• 失敗するテストなしで本番コードを書いてはいけない
• テストが正しい理由で失敗していることを必ず確認する
• テストを通すために必要最小限のコードだけを書く
• すべてがグリーンになってからリファクタリングする

さらに、脆くてあてにならないテストを避けるための専用ガイド testing-anti-patterns へのリンクも含まれています。

想定ユーザー

test-driven-development スキルは、次のような人に向いています。

• 機能開発・バグ修正・リファクタリングを、安定したワークフローで進めたい 開発者
• チームとして TDD を標準化し、誰でも従える明確なルールが欲しい 開発チーム
• テスト自動化の習慣を、組織として徹底したい コーチ / テックリード

JavaScript や TypeScript のコードベースで特に有用ですが、原則は言語やテストフレームワークを問わず適用できます。

このスキルが解決する課題

このスキルは、日々の開発でありがちな次のような問題を解消するために設計されています。

• 先にコードを書き、後から（あるいは結局は書かずに）テストを追加してしまう
• テストが本当に振る舞いを検証できているか自信が持てない
• テストが弱い、あるいは存在しないためにリファクタリングが怖い
• モックを過剰／誤用し、現実の振る舞いではなく「作り物の動き」だけをテストしてしまう

test-driven-development のワークフローに従うことで、次のようなメリットが得られます。

• 失敗するテストからの 素早いフィードバック
• 仕様としての 期待される振る舞いの記録 が残る
• テストで振る舞いが固定されるため、リファクタリングが格段に安全 になる
• モックや実装詳細だけを検証する脆いテストを避けられる

いつ使うべきか（そして、いつは使わなくてよいか）

アップストリームのスキルでは、TDD を特に次の場面で使うことを推奨しています。

• 新機能の開発
• バグ修正
• リファクタリング
• あらゆる振る舞いの変更

一方で、次のようなケースは、人間のパートナーと相談して例外にするよう明示されています。

• 使い捨てのプロトタイプ
• 自動生成されたコード
• 設定ファイル

「とりあえず動かしてみる」「捨てる前提のスパイクを軽く試す」といった場面では、この厳密な test-driven-development スキルは過剰かもしれません。しかし本番向けの機能については、このスキルは 標準のワークフロー として使うことを意図しており、「余力があればやるオプション」ではありません。

使い方

インストール

obra/superpowers リポジトリから test-driven-development スキルをインストールするには、次のコマンドを実行します。

npx skills add https://github.com/obra/superpowers --skill test-driven-development

これにより、test-driven-development のスキル定義と関連ファイルが Agent Skills 環境に取り込まれます。インストール後は、スキルのファイルを開くことで、詳細なルールやアンチパターンの具体例を確認できます。

このスキルが参照する主なファイルは次のとおりです。

• SKILL.md – Iron Law や Red-Green-Refactor を含むコアの TDD ルール
• testing-anti-patterns.md – テストで「やってはいけないこと」に特化したガイド

コア原則: Iron Law

このスキルの中心には、ソースで Iron Law と呼ばれているルールがあります。

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

実務的には、次のような意味になります。

• もしテストより先に本番コードを書いてしまった場合、そのコードは 削除して書き直す
• テストを書きながら「参考用コード」として残しておくことは しない
• テストを書き直すときに、削除したコードを 見返してはいけない

この強いルールによって、あらゆる本番コードの 1 行 1 行が、実際のテストによって駆動されていることが保証されます。

ステップごとの TDD ワークフロー

test-driven-development スキルをインストールしたら、これを標準のワークフローとして適用します。

1. 失敗するテストを書く（RED）

• 対象とする 単一の振る舞い（機能・バグ修正・リファクタの結果）を決める
• 期待する振る舞いを表現する 新しいテスト を書く
• テストを実行し、この新しいテストが 確かに失敗する ことを確認する

RED のステップは、次の条件を満たすまで完了ではありません。

• テストが失敗している
• その失敗が 正しい理由（正しいアサーション／正しいエラー）によるものである

もし失敗の仕方がおかしい（例: テストがクラッシュしている、セットアップで落ちているなど）場合は、意味のある形で失敗するようテストを修正し、再度実行します。

2. テストを通すための最小限のコードを書く（GREEN）

• 失敗しているテストを通すために必要な、最も単純なコード だけを実装する
• 先回りした設計や抽象化、余計なロジックは避ける
• テストスイートを実行し、新しいテストが グリーン で、既存テストもすべて通っていることを確認する

このステップでは、「機能を全部作り込む」ことではなく、あくまで テストを満たすこと に徹するよう強く促されています。

3. 安全にリファクタリングする（REFACTOR）

すべてのテストがグリーンになったら、次を行います。

• 本番コードの整理: 重複の削除・ロジックの単純化・名前の改善
• テストコードの整理: 可読性向上のためのリライトや、必要に応じたヘルパー抽出
• 振る舞いが変わっていないことを確かめるため、テストを頻繁に実行し続ける

テストスイートに支えられながら、振る舞いは保ったまま設計を改善していくステップです。

4. このサイクルを繰り返す

小さな振る舞いやエッジケースごとに、次を繰り返します。

• テストを追加する（RED）
• テストを通すコードを書く（GREEN）
• 必要に応じてリファクタリングする（REFACTOR）

test-driven-development スキルの役割は、常にこのループの中にいられるよう導き、どこかのステップを飛ばして自分に言い訳する余地を減らすことです。

既存のスタックへの統合

リポジトリに含まれる例は主に JavaScript と TypeScript にフォーカスしていますが、TDD のルール自体はどのスタックでも同じように適用できます。

• JavaScript/TypeScript プロジェクト（Jest, Vitest, Mocha など）では:

  • 本番コードを編集する 前に、必ずテスト（*.test.ts や *.spec.ts など）を新規作成・修正する
  • アプリケーションコードのあらゆる変更で、Red-Green-Refactor のサイクルを回す

• その他の言語（Python, Java, Go, C# など）では:

  • 自分のテストフレームワーク（pytest, JUnit, Go test, xUnit など）に同じステップを対応づける
  • 「失敗するテストなしで本番コードを書かない」という厳格なルールは、同じように適用される

このスキル自体は、特定のフレームワークに縛りつけるものではなく、ライブラリ依存ではなくワークフローのルール を定義するものです。

testing anti-patterns ガイドの活用

同梱されている testing-anti-patterns.md は、test-driven-development スキルの相棒となるガイドです。次のようなときに読み返したりロードしたりしてください。

• テストを書いている、あるいは変更しているとき
• モックやスタブを追加しようとしているとき
• 本番クラスやモジュールに、テスト専用のフックを足したくなったとき

このガイドで特に重要な原則は次のとおりです。

• モックの振る舞いだけをテストしない – テストは、モックが存在することではなく、本物の振る舞いを検証すべき
• テスト専用メソッドを本番クラスに追加しない – 本番 API は常にクリーンに保つ
• 依存関係を理解せずにモックしない – モックの乱用は、誤った安心感につながる

アンチパターンの例は TypeScript スタイルのテストで示されており、自分が使っているテストフレームワークにも応用しやすくなっています。

チームに合わせてワークフローを調整する

インストール後は、test-driven-development スキルのルールをチームの現実に合わせて調整しつつ、コアの意図は守るようにします。

• どの種類の変更に対しては厳密な TDD を 必須 とするか（例: すべての本番モジュール、ドメインロジック、重要なフローなど）をチームで決める
• 例外ケース（短命なスパイクや生成コードなど）は少数にとどめ、明示的に合意しておく
• コードレビューのチェックリストに Iron Law を組み込む:
  • 「この変更を駆動した失敗するテストはどれか？」
  • 「そのテストは最初に書かれているか？」

こうすることで、このスキルを単なる個人の習慣ではなく、チーム標準 として活用できます。

FAQ

test-driven-development スキルは特定のテストフレームワークに依存しますか？

いいえ。test-driven-development スキルが定義しているのは、特定のテストフレームワークではなく ワークフローとルール です。リポジトリの例は JavaScript と TypeScript に寄っていますが、Red-Green-Refactor のループ自体はどの言語でも同じように適用できます。

テストを書かずに書いてしまったコードは、本当に削除しないといけませんか？

SKILL.md の Iron Law に従うと、答えは「はい」です。失敗するテストより先に本番コードを書いてしまった場合、そのコードは 削除し、テストから書き直す のがルールです。テストを「後回しのオマケ」にしないための仕掛けです。

このスキルが向いていないケースは？

アップストリームのガイドでは、使い捨てプロトタイプ、自動生成されたコード、設定ファイルなど、いくつかの例外候補が挙げられています。短期間だけ使う実験的なスパイクには、厳密な test-driven-development はやや重すぎるかもしれません。一方で、本番向けの機能・バグ修正・リファクタリングについては、このスキルはデフォルトとして使うことを意図しています。

このスキルはデバッグやリファクタリングにどう役立ちますか？

バグ修正やリファクタリングを行うときは、次のように進めます。

• まず、そのバグを再現する、あるいは望ましい振る舞いを表す失敗するテストを書く
• 次に、そのテストが通るまでコードを変更する
• 最後に、テストが振る舞いを保証してくれている状態で、安心してリファクタリングする

これにより、デバッグの手順が体系立てられ、リファクタリングもずっと安全になります。

テストがない既存のレガシーコードにも、このスキルは使えますか？

はい。ただし、多くの場合は 段階的に適用 していくことになります。

• レガシーな箇所に手を入れるとき、まず現在の振る舞いまたは望まれる振る舞いを捉えたテストを追加する
• （振る舞いを変えるのであれば）テストが失敗するのを確認してから、そのテストを通す
• その後は Red-Green-Refactor のループを回しながら、その部分のコードを徐々にテストで保護していく

こうして時間をかけて、レガシーコードのより多くの部分をテストで守られた状態にできます。

インストール後、最初に何をすればよいですか？

インストールコマンドを実行したら、次のファイルを開いてください。

• SKILL.md: test-driven-development のコアなルールと、Red-Green-Refactor の解説
• testing-anti-patterns.md: テストを書くときに避けるべき典型的なミスの一覧

日々の開発ワークフローのリファレンスとして、これら 2 つのファイルを活用してください。