スキル test-driven-development
📦

test-driven-development

安全

テスト駆動開発を適用する

こちらからも入手できます: Cycleaddict,davila7,DMJGilbert,DYAI2025,Cygnusfear,CodingCossack,obra

コードの後にテストを書くことは、誤った自信と見逃されたエッジケースにつながります。このスキルは TDD の規律を強制します：まず失敗するテストを書き、その後それをパスするために必要な最小限のコードを実装します。

対応: Claude Codex Code(CC)
🥉 74 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「test-driven-development」を使用しています。 メールアドレスを検証する関数を追加する必要があります

期待される結果:

TDD で始めましょう。まず、失敗するテストを書きます：

```typescript
test('rejects invalid email', () => {
expect(validateEmail('invalid')).toBe(false);
});
```

次にこのテストを実行して失敗することを確認します...

「test-driven-development」を使用しています。 login 関数は間違ったパスワードを処理できる必要があります

期待される結果:

TDD に従って、まずテストを書きます：

```typescript
test('rejects wrong password', async () => {
const result = await login('user@test.com', 'wrongpass');
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
});
```

テストを実行して失敗することを確認します...

セキュリティ監査

安全
v1 • 2/24/2026

This is a legitimate Test-Driven Development educational skill. The static analyzer detected 73 potential issues, but after semantic evaluation, all findings are FALSE POSITIVES. The 'external_commands' detections are markdown code block delimiters (backticks) in documentation, not actual shell execution. The 'weak cryptographic algorithm' and 'network reconnaissance' detections are similarly false positives triggered by keywords in educational context. No executable malicious code exists in this skill.

2
スキャンされたファイル
672
解析された行数
1
検出結果
1
総監査数
中リスクの問題 (1)
Markdown Code Block Delimiters Flagged as Shell Execution
The static scanner detected 'Ruby/shell backtick execution' patterns in markdown files. These are FALSE POSITIVES - the backticks are markdown code fence delimiters (```typescript, ```bash) used for syntax highlighting in documentation, not runtime command execution. The skill is educational content about TDD methodology with no actual shell commands being executed.
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

新機能の実装

新機能を構築する際、期待される動作を定義するテストを最初に書き、失敗することを確認してから、それをパスするように実装する

バグ修正ワークフロー

バグを修正する際、まずバグを再現するテストを書き、失敗することを確認してから、コードを修正してパスさせる

自信を持ったリファクタリング

リファクタリングの前に、テストが存在することを確認する。テストにより、コード変更後も動作が正しいことが検証される

これらのプロンプトを試す

新機能の TDD を開始する 
[機能の説明] を実装する必要があります。TDD に従って、まず期待される動作を定義する失敗するテストを書いてください。まだ実装コードは書かないでください。
Red フェーズの検証 
私が書いたテストを実行して、正しい理由で失敗することを確認してください（機能がないためであり、タイプミスなどではありません）。正確なエラーメッセージを表示してください。
Green フェーズ - 最小限の実装 
次に、テストをパスするために必要な最小限のコードを書いてください。追加機能やリファクタリングは行わないでください。テストをパスさせることだけに集中してください。
バグ修正の TDD 
[バグの説明] というバグがあります。まずこのバグを再現して失敗するテストを書いてください。その後修正します。

ベストプラクティス

  • 一度に 1 つのテストを書く - 単一の動作に集中する
  • テスト名は、何をテストしているかではなく、検証する動作によって命名する
  • 実装を書く前に常にテストが失敗することを確認する
  • 実装は最小限に - 現在のテストをパスするだけにする

回避

  • テストの前に実装コードを書く（その後テストを「適合」させる）
  • テストを書きながら、失敗した実装コードを「参考」として保持する
  • すぐにパスするテスト - 何も証明していない
  • 実際のコンポーネントの動作ではなく、モックの動作をテストする

よくある質問

テスト駆動開発とは何ですか？
TDD は、まず失敗するテストを書き、それをパスするための最小限のコードを書き、その後リファクタリングする手法です。サイクルは：Red（失敗）、Green（パス）、Refactor です。
なぜコードの前にテストを書くのですか？
コードの後に書かれたテストはすぐにパスしてしまい、何も証明しません。最初にテストを書くことで、期待される動作を定義し、テストが実際にバグを検知することを証明できます。
テストが書きにくい場合はどうすればよいですか？
テストが書きにくい場合、デザインが複雑すぎることを示しています。インターフェースを単純化するか、依存性注入を使用してコードをテストしやすくします。
シンプルなコードでは TDD をスキップできますか？
いいえ。シンプルなコードでも壊れます。テストを書く時間は最小限であり、コードが動作することを証明し、将来の回帰を防ぎます。
すでに実装を書いてしまった場合はどうすればよいですか？
削除してください。TDD で新しく始めてください。既存のコードを保持して後にテストを追加するのは、TDD の目的に反し、誤った自信を与えます。
TDD は開発を遅くしますか？
いいえ。TDD はコミット前にバグを見つけ、回帰を防ぎ、安全なリファクタリングを可能にします。事後のデバッグは TDD よりも遅いです。

開発者の詳細

作成者

ZhanlinCui

ライセンス

MIT

リポジトリ

https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/test-driven-development

参照

main

ファイル構成

📄 SKILL.md

📄 testing-anti-patterns.md