test-driven-development
テスト駆動開発ワークフローを習得する
こちらからも入手できます: ZhanlinCui,DMJGilbert,Cycleaddict,davila7,DYAI2025,CodingCossack,Cygnusfear,obra
コードを書いた後にテストを書いても、それが実際に何かをテストしているという証明にはなりません。このスキルは Red-Green-Refactor サイクルを強制し、実装前にすべてのテストが失敗することを確認することで、テストが実際の動作を検証することを保証します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「test-driven-development」を使用しています。 失敗した操作を 3 回再試行する関数を実装する
期待される結果:
- ステップ 1 (RED): '失敗した操作を 3 回再試行する' テストを書く
- ステップ 2: テストを実行 - 再試行ロジックが存在しないため失敗することを確認
- ステップ 3 (GREEN): 最小限の再試行ループを実装
- ステップ 4: テストを実行 - パスすることを確認
- ステップ 5 (REFACTOR): 必要に応じて再試行ロジックを抽出
「test-driven-development」を使用しています。 バグ：空のメールがフォームで許可されている
期待される結果:
- RED: test('空のメールを拒否する') - エラー 'Email required' を期待
- 検証：テストが失敗 - フォームは現在空のメールを許可している
- GREEN: 空のメールのバリデーションチェックを追加
- 検証：テストがパス、回帰なし
- 結果：回帰を防止するテスト付きでバグ修正
セキュリティ監査
安全This skill contains only markdown documentation explaining test-driven development methodology. All 57 static analyzer findings for external_commands are false positives - the detected backticks are markdown code fences (```) used for syntax highlighting, not Ruby shell execution. The 6 cryptographic algorithm findings and reconnaissance detections are also false positives from pattern matching on documentation text. No executable code, network calls, or filesystem operations exist in this skill.
品質スコア
作れるもの
新機能開発
コミット前に正しい動作を証明する対応するテストが各関数にあることを保証するために、新機能を実装する際に TDD を使用する
回帰防止を含むバグ修正
まずバグを再現する失敗するテストを書き、その後修正を実装し、バグが再発しないことを保証する
自信を持ったリファクタリング
コードの再構築や最適化中に動作が変わらないことを検証するために、既存のテストスイートを使用する
これらのプロンプトを試す
[feature] を実装する必要があります。まず期待される動作を記述する失敗するテストを書くのを手伝い、その後 Red-Green-Refactor をガイドしてください。
バグ：[describe bug]。このバグを再現するテスト（失敗するはず）を書くのを手伝い、その後それをパスさせる最小限の修正を実装してください。
[function] の私のテストをレビューしてください。それは実際の動作をテストしていますか、それともモックの動作をテストしていますか？テスト名は明確ですか？1 つのことをテストしていますか？
[action] を行おうとしています。これが TDD 原則に違反していないか確認してください。モックの動作をテストしていませんか？テスト専用のコードを追加していませんか？理解せずにモックしていませんか？
ベストプラクティス
- 実装する前に必ずテストが失敗することを確認 - これがテストが実際に何かをテストしていることの証明になる
- テストをパスさせるための最小限のコードだけを書く - 余分な機能も過剰設計もしない
- TDD サイクルをスキップした場合は実装コードを削除し、テストファーストで最初からやり直す
回避
- テストが存在する前に実装コードを書くこと
- 実際のコードの動作ではなくモックの動作をテストすること
- 本番クラスにテスト専用メソッドを追加すること
よくある質問
すでに実装コードを書いてしまった場合はどうすればよいですか？
実装後にテストを書くことはできますか？
コードが単純すぎてテストできない場合はどうすればよいですか？
テストのない既存のコードはどのように扱えばよいですか？
テストセットアップが複雑すぎる場合はどうすればよいですか？
TDD をスキップできるのはいつですか？
開発者の詳細
作成者
sickn33ライセンス
MIT
リポジトリ
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/test-driven-development参照
main
ファイル構成