test-driven-development

test-driven-development skill の概要

test-driven-development skill が実際にしてくれること

test-driven-development skill は、機能追加・バグ修正・振る舞い変更に対して、AI エージェントに厳密な TDD の進め方を守らせるための skill です。最初にテストを書く、正しい理由で失敗していることを確認する、通すための最小限の本番コードを書く、その後に安全にリファクタリングする――この順序を徹底します。価値の中心は「ついでにテストも書く」ことではなく、実行可能な振る舞いを起点に実装を進めるよう強制できる点にあります。

この skill が向いている人

この test-driven-development skill は、AI を実際のリポジトリ作業に使っていて、正しさが重要な開発者に向いています。たとえばアプリ機能、サービスロジック、バグ修正、リファクタリング、リグレッション防止などです。特に、モデルがいきなり実装に飛びつくのを止めて、より小さく検証可能なステップで進めさせたい場面で効果を発揮します。

この skill が解決する本当の課題

多くのユーザーが test-driven-development を導入する理由は、一般的なコーディング用プロンプトだと先にコードを書き、テストは後付けになりがちだからです。この skill はその挙動を変えます。失敗するテストを起点に実装を固定できるため、エージェントの出力をレビューしやすくなり、未検証の振る舞いを作り込むリスクも減らせます。

汎用的な「テストを書いて」プロンプトとの違い

違いは、この skill にある「鉄則」です。失敗するテストが先にない限り、本番コードを書かない。このルールは、普通のプロンプトよりはるかに厳格です。さらに、最初の失敗が「何でもいい赤」ではなく、狙った欠落した振る舞いによる正しい失敗かどうかを確認する点も重視しています。これは実務上かなり重要なガードレールですが、表面的な TDD 解説では見落とされがちなポイントです。

インストール前に知っておきたい制約

これはプロセスを与える skill であり、特定フレームワーク向けのテストツールキットではありません。テスト全体のアーキテクチャを丸ごと決めてくれるわけではなく、補助スクリプトや詳細なリファレンスも SKILL.md と testing-anti-patterns.md 以上には含まれていません。Jest、Pytest、JUnit、Playwright などの深いセットアップ手順が必要なら、この skill は完全なテスト手引きというより、既存環境の上に載せるワークフローレイヤーとして使うのが適しています。

test-driven-development skill の使い方

test-driven-development skill をインストールする

次のコマンドでリポジトリからインストールします。

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

ローカルで skill を自動検出できる環境なら、機能開発を始める前に test-driven-development として表示され、エージェントから利用可能になっていることを確認してください。

まず読むべきファイル

この test-driven-development install と利用フローでは、最初に次のファイルを確認してください。

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

まずはワークフローと制約を把握するために SKILL.md を読みます。次に、モック、分離、UI テスト、あるいは本番コードにテスト専用の継ぎ目を足したくなるような状況があるなら、testing-anti-patterns.md を確認してください。

skill が最低限必要とする入力を把握する

この skill が最も機能しやすいのは、次の情報を渡したときです。

• 対象の機能、バグ、または振る舞い変更
• 関連ファイル、あるいはモジュール境界
• リポジトリですでに使っているテストフレームワーク
• ユーザーから見える、またはシステムから見える期待動作
• API 形状、後方互換性、性能に関する制約

こうした前提がなくても、エージェントは機械的に TDD を適用できます。ただしその場合、テストレベルを誤ったり、コードベースよりツール都合に寄った不自然なテストを書いたりしやすくなります。

あいまいな依頼を TDD 向きのプロンプトに変える

弱いプロンプト:

Add support for password reset.

より良いプロンプト:

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

後者のほうが、エージェントが最初に書くべきテストを正しく選び、red-green-refactor のサイクルを守るのに十分な文脈を与えられます。

一括生成ではなく、段階的なワークフローとして使う

実用的な test-driven-development usage パターンは次のとおりです。

1. まず最初の失敗するテストだけを依頼する。
2. その失敗が意図した振る舞いを指しているか確認する。
3. 通すための最小実装だけを依頼する。
4. green になってからリファクタリングを依頼する。
5. 次の小さな振る舞い単位で繰り返す。

この skill は、小さく検証された増分を前提に設計されています。そのため、機能全体を一度に生成させるより、この進め方のほうが結果が安定します。

“red” フェーズを正しく確認する

この test-driven-development guide で重要なのは、単にテストが失敗していればよいわけではないという点です。その失敗が、狙った未実装の振る舞いを確かに示していなければなりません。import エラー、壊れた fixture、無関係なセットアップ不備で落ちているなら、TDD のサイクルはまだ始まっていません。

プロンプトでは、なぜそのテストが失敗しているのか、そしてなぜその失敗が正しいのかを、エージェントに明示的に説明させるのが有効です。

test-driven-development で最初に書くべきテストを選ぶ

最初のテストは通常、外から意味のある最小の振る舞い変更を狙うのが適切です。よい候補は次のようなものです。

• バグ再現
• 1つの業務ルール
• 1つの endpoint のレスポンス変更
• 1つのドメインメソッドの振る舞い
• ユーザー影響が明確な 1つの UI 操作

逆に、巨大な end-to-end シナリオ、広すぎる snapshot カバレッジ、内部実装を早い段階で固定してしまうテストは、出発点として適していません。

モックが出てきたら anti-pattern ガイドを適用する

エージェントがモックを使いすぎ始めたら、補助ファイルの testing-anti-patterns.md が重要になります。この skill は、実際の振る舞いではなくモックの振る舞いをテストすることに強く警鐘を鳴らしています。特に test-driven-development for Test Automation の文脈では、AI エージェントは実出力より満たしやすいという理由で、モックの置き物に対するアサーションを書きがちです。

「モックがレンダリングされた」「モックが形式的に呼ばれた」「テストのためだけのメソッドを本番コードに追加した」といった内容をテストが主張し始めたら、いったん止めてテストのスコープを見直してください。

エージェントに鉄則を守らせる

もしモデルがすでに実装コードを書いてしまっているなら、この skill 自体の指針は明確です。いったん本番コードを捨て、失敗するテストからやり直すべきです。実際には大げさに構える必要はありませんが、先に出た推測ベースの実装は無視し、テストファーストの順序で生成し直すよう指示してください。

使いやすい指示文:

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

リポジトリのテストスタックに合わせて使う

この skill はプロセス中心なので、使う際は自分のスタックにしっかり紐づける必要があります。

• Python サービスなら pytest
• JS/TS ロジックなら Jest または Vitest
• Ruby なら RSpec
• Java なら JUnit
• Playwright などは、その振る舞いが本当にブラウザレベルに属するときだけ

リポジトリにすでに強いテストピラミッドがあるなら、この変更がどの層に入るべきかをエージェントに伝えてください。そうしないと、最も目立つテスト形式に寄ってしまい、最も安くて有効なテストを選べないことがあります。

実際のリポジトリ作業向けプロンプト例

実務で使いやすい test-driven-development skill のプロンプト例は次のような形です。

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

このプロンプトには、振る舞い、対象箇所、フレームワーク、レビュー基準がそろっています。

test-driven-development skill FAQ

すでに TDD を知っていても、test-driven-development は入れる価値がある？

あります。特に課題が「AI エージェントに TDD を本当に守らせること」であって、TDD の知識そのものではないなら有効です。test-driven-development skill は学習用途というより、モデルに行動上の制約をかけるためのものとして役立ちます。

初心者でも使いやすい？

概ね使いやすいです。ワークフロー自体はシンプルで明示的です。初心者にとって難しいのは、最初のテストと適切なテストレベルを選ぶ部分でしょう。テスト経験が浅いなら、幅広い新機能より、まずは小さなバグ修正でこの skill を試すのがおすすめです。

test-driven-development が向かないのはどんなとき？

使い捨てのプロトタイプ、生成コード、設定ファイルだけの変更では、相性はやや落ちます。例外は、正しさのリスクが高く、人間のレビュー担当もテストファーストの規律を求めている場合です。元のガイダンスでも、こうしたケースは人間の相棒と相談すべき例外として明示されています。

普通のプロンプトと何が違う？

一般的なプロンプトは「X を実装してテストも追加して」で終わりがちです。この skill は作業順序そのものを変え、その順番を譲れない前提として扱います。価値の本体はこの順序制御にあり、実装の幻覚を減らし、レビューしやすさを上げてくれます。

フレームワークのセットアップまでカバーしている？

深くはカバーしていません。test-driven-development install 自体は簡単ですが、skill 本体にフレームワーク別の詳細なセットアップ文書が豊富にあるわけではありません。既存のテストスタックやリポジトリ慣習を、ユーザー側からエージェントに示せる前提です。

test-driven-development はリファクタリングにも使える？

使えます。振る舞いを維持したまま進めたいリファクタリングには相性がよいです。実務上の進め方としては、まず現行の振る舞いをテストで固定し、その後 green のテストに守られた状態でリファクタリングします。

UI や end-to-end テストにも向いている？

場合によりますが、注意して使う必要があります。UI 作業では anti-pattern ファイルが特に重要で、AI がモックの存在や実装由来の痕跡を検証する方向に流れやすいためです。まずは、本当に検証可能な最小のユーザー行動から始めてください。

test-driven-development skill を改善する方法

解法ではなく振る舞いを渡す

よりよい test-driven-development usage にしたいなら、実装案を細かく指示するより、期待する振る舞いと制約を伝えるほうが効果的です。TDD は、テストが結果を定義し、コードがそこから立ち上がるときに最も機能します。

よい入力:
Users should see an error when uploading files over 10MB.

よくない入力:
Add a fileSizeValidator class and call it from the controller.

前者のほうが、よりクリーンで最小限の実装にたどり着きやすくなります。

欲しいテストレベルを明示する

結果が弱くなる大きな原因の一つが、テストのスコープ不一致です。次のどれを望んでいるのかを、最初からエージェントに伝えてください。

• unit レベルの業務ロジック
• サービスや API を囲む integration
• ブラウザレベルの振る舞い

この 1 点だけで、他の細かなプロンプトより結果が大きく変わることも珍しくありません。

変更単位をもっと小さくする

よくある失敗は、1 サイクルに詰め込みすぎることです。モデルが広いテストスイートと大きな実装を同時に書いてきたら、依頼を絞ってください。

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

これで test-driven-development のループを崩さずに済みます。

最初のテストが正しい理由を説明させる

次の点をエージェントに説明させてください。

• なぜこのテストが最小で有用な 1 スライスなのか
• どの失敗が起きる想定なのか
• なぜその失敗で、振る舞いの欠落が証明できるのか

これにより、実装前に隠れた前提が表に出るため、品質が上がります。

anti-pattern を早めに監視する

品質が落ちる典型パターンは次のとおりです。

• 振る舞いではなくモックをテストしている
• 本番コードにテスト専用メソッドを入れている
• 先に通るテストを書いて TDD だと言い張る
• 実装詳細に結びついたアサーションを選んでいる
• green になった後のリファクタリングを飛ばしている

どれかが見えたら、その場しのぎで継ぎ足すのではなく、サイクルを止めて最初のテストを正した形でやり直させるほうが有効です。

リポジトリ慣習を明示する

次のような情報を渡すと、この skill の出力はかなり改善します。

• テストの命名規則
• テストの配置場所
• fixture のパターン
• モックの方針
• 好みのアサーションスタイル

このリポジトリには軽い補助資料しかないため、こうしたローカルルールが出力品質に直接効いてきます。

最初の出力のあとに改善をかける

最初の結果に対して、ただ「続きを」と頼むのは避けてください。代わりに、焦点のある追質問を返します。

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

実運用で test-driven-development skill を改善するうえで最も効くのはこれです。エージェントをサイクルの中に留め、先走らせないことが重要です。

例外ケースは人間の判断と組み合わせる

この skill は意図的に厳格です。それは長所ですが、適用しすぎることもあります。作業が純粋な設定変更、生成コードの更新、使い捨てプロトタイプであれば、完全な TDD に見合うコストかを考えてください。より良い結果が出るのは、「適用できる場所」ではなく、「テストファーストの順序が意思決定の質を変える場所」に使ったときです。