test-driven-development

test-driven-development skill の概要

test-driven-development skill は、まず振る舞いをテストで証明し、そのあとでテストを通す最小限の修正を実装することで、コード変更を安全に進めるための skill です。ロジック変更、バグ修正、エッジケース、回帰対応のように、「見た目が正しそう」だけでは不十分な作業に向いています。test-driven-development skill を使って迷いを減らしたいなら、このガイドで、その skill がどんな場面に合うのか、そして実際に何を改善できるのかを確認できます。具体的には、より安全な編集、要件の明確化、初回パッチ後の手戻り削減です。

この skill の用途

test-driven-development は、挙動が変わるタスクで使います。たとえば、新しい関数の追加、条件分岐の変更、バグの再現、あるいは既存コードを静かに壊してしまう可能性のある変更です。すでにリポジトリにテストがあり、エージェントにゼロから振る舞いを想像させるのではなく、プロジェクトの証明システムの中で作業させたいときに特に有効です。

何が違うのか

この skill の核は、まず失敗するテストを書き、そのテストが証明した範囲だけを実装するという дисциплина にあります。これにより、エージェントには明確な到達点ができ、前提の抜け漏れが早い段階で露見し、修正範囲も小さく保ちやすくなります。test-driven-development for Skill Testing では、これが「それらしいパッチ」と「検証済みのパッチ」の違いになることがよくあります。

向かないケース

実行時の振る舞いが変わらない変更には、この skill を使わないでください。たとえば、コピーの文言修正、静的コンテンツの更新、純粋な設定変更です。プロジェクトのテストカバレッジがほとんどない場合でも skill 自体は役立ちますが、まずテストハーネスの準備が必要になりやすく、ワークフローの効果が出るまで時間がかかります。

test-driven-development skill の使い方

skill をインストールして確認する

test-driven-development install のリポジトリ導入フローを使います。

npx skills add addyosmani/agent-skills --skill test-driven-development

インストール後は、まず SKILL.md を読みます。このリポジトリには rules/、resources/、scripts/ のような追加フォルダがないため、主な作業は skill ファイルを丁寧に読み、その指針を自分のコードベースにどう当てはめるかを見極めることです。

あいまいな依頼をテスト可能な指示に変える

test-driven-development usage は、解決策ではなく振る舞いの記述から始めるのが最も効果的です。良い指示の例は、「空の email の検証について失敗するテストを追加し、そのあと src/auth.ts に最小修正を入れてください」です。弱い指示は、「login を改善して」です。観測可能な結果、分かっているなら対象のファイルやモジュール、そして気にしている回帰リスクを含めてください。

RED-GREEN-REFACTOR の流れに従う

この skill はワークフローとして使います。まず現行コードで失敗するテストを書き、次にそれを通す最小のコード変更を加え、最後にテストが通ったままならリファクタリングをします。失敗を再現しづらいときは、実装に触る前にいったん止まり、テストケースをより明確にしてください。失敗ケースが十分に具体的であってこそ、バグを証明できます。

先に読むべきファイルを見極める

このリポジトリでは、最初に読むべきなのは SKILL.md です。そのあと、対象プロジェクトのローカルなテスト設定を確認してください。テストランナーの設定、既存のテスト規約、そして変更予定コードの近くにあるテストです。すでに強いパターンがあるならそれに厳密に従い、そうでないならテストは最小限かつ明示的に保ちます。

test-driven-development skill の FAQ

これは経験者向けだけですか？

いいえ。初心者でも test-driven-development は使えますが、出発点は明確である必要があります。1 つの振る舞い、1 つの失敗するテスト、1 つの最小修正です。この skill は、広い機能開発よりも、小さなバグ修正で学びやすいです。

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

普通のプロンプトは、コードが「動く」ことを求めるかもしれません。この skill は証拠を求めます。test-driven-development guide は、成功の定義を通るテストに置き換えるようエージェントを促し、曖昧さを減らしてレビューもしやすくします。

どんなときに選ばないほうがいいですか？

ドキュメント修正、整形、あるいは実行時の振る舞いとして表せない変更では避けてください。テストハーネスが実用的でなく、しかも必要なのが動作に関係しない軽微な編集だけなら、これも避けるべきです。

どのエコシステムにも合いますか？

原理上ははい、ですが、具体的なテストコマンド、アサーション、ファイル構成はスタックに依存します。skill 自体はフレームワーク非依存です。実際には、ローカルのリポジトリ規約によって、Jest、Vitest、pytest、JUnit、あるいは別のランナーを使うかが決まります。

test-driven-development skill の改善方法

エージェントにより鋭い失敗ケースを渡す

最も強い指示は、失敗する振る舞い、期待結果、境界条件を具体的に名指しします。例: 「parseDate("") が実行されたら InvalidDateError を投げるべきです。まずテストを追加し、そのあとパーサーを修正してください。」こうすると、test-driven-development skill が曖昧な実装推測に流れにくくなります。

既存のテストスタイルを共有する

近い位置にあるテストファイル、命名パターン、プロジェクトで既に使っているヘルパーやフィクスチャがあれば伝えてください。同様の振る舞いに対してテーブル駆動テスト、モック、統合テストを使っているなら、その点も明記します。ローカルの規約に合わせるほど信頼性が上がり、マージしやすい出力になります。

よくある失敗パターンに注意する

最大のミスは、テストより先に実装を書くこと、すでに通ってしまうテストを使うこと、失敗ケースを超えて修正範囲を広げすぎることです。最初の出力が広すぎるなら、最小限の失敗テストと、単一の最小パッチだけを求め直してください。それが、信頼できる test-driven-development usage に最短で到達する方法です。

推測ではなく証拠で反復する

最初のパスのあとには、次の証拠点を求めてください。別のエッジケース、回帰テスト、あるいは通過中のテストを保ったまま行うリファクタリングです。バグが微妙な場合は、変更前後の挙動の要約と、追加すべき正確なテスト名を依頼してください。そうすることで、ワークフローを前提ではなく観測可能な振る舞いに固定できます。