📦

tdd

安全

テスト駆動開発でテストを書く

こちらからも入手できます: Benny9193

コードの後にテストを書くと、リファクタリングで壊れやすいシステムが生まれます。このスキルでは、実装前にテストで動作を定義するテスト駆動開発をガイドし、よりクリーンなコードと信頼性の高いリファクタリングを実現します。

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

スキルZIPをダウンロード

2

Claudeでアップロード

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

3

オンにして利用開始

テストする

「tdd」を使用しています。 ショッピングカートにアイテムを追加する機能を構築するのを手伝ってください

期待される結果:

この機能のTDDをガイドします。最初の質問:ユーザーがアイテムを追加するとき、何が起こるべきか?数量のサポートはありますか?検証可能な動作は何ですか?

「tdd」を使用しています。 ユーザー認証のテストを書いてください

期待される結果:

認証テストでは、パブリックインターフェースに焦点を当ててください:ログイン、ログアウト、セッション処理。内部認証ロジックのモックよりも統合テストスタイルを推奨します。認証ではどんな外部サービスを使用していますか?

「tdd」を使用しています。 リファクタリングするたびにテストが壊れます

期待される結果:

テストは実装の詳細に結合している可能性があります。良いテストはパブリックインターフェースを通じて動作を検証します。どのテストが壊れるか、そして何をチェックしているか特定しましょう。

セキュリティ監査

安全
v1 • 4/19/2026

All 48 static findings are false positives. The skill contains educational TDD documentation with code examples. External command flags were triggered by ASCII workflow diagrams (RED→GREEN patterns). Cryptographic algorithm flags were triggered by testing patterns like jest.mock() and StripeClient(). No malicious code or prompt injection detected.

6
スキャンされたファイル
307
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

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

作れるもの

TDDで新機能を構築する

新機能の開始時に、このスキルは期待される動作を定義するテストを先に書き、そのテストを通過するための最小限の実装をガイドします。

失敗するテストでバグを修正する

バグが報告されたとき、このスキルはバグを再現する失敗するテストを書き、テストを通過するためにコードを修正するのをガイドします。

リファクタリングによるレガシーコードの改善

レガシーコードのリファクタリング前に、このスキルは現在の動作をキャプチャする統合テストを書き、リファクタリングが既存の機能を壊さないことを確認します。

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

TDDで新機能開発
[モジュール]に[機能]を追加する必要があります。TDDを使って構築するのを手伝ってください。最初にテストする動作を聞いてください。
TDDでバグ修正
[説明]にバグがあります。再現する失敗するテストを書き、それから修正を手伝ってください。
テストカバレッジの改善
[モジュール]により良いテストが欲しいです。現在のテストを確認し、TDDの原則に従って改善を提案してください。
自信を持ってリファクタリングする
[モジュール]をリファクタリングしたいしたいです。最初に現在の動作をキャプチャするテストを書くのを手伝い、それからリファクタリングをガイドしてください。

ベストプラクティス

  • 一度に1つのテストを書き、それをパスするためだけに十分なコードを書く
  • パブリックインターフェースのみを使用し、テストは内部リファクタリングに耐えるべき
  • 内部パーツのモックよりも、観察可能な動作を検証する統合テストを好む

回避

  • すべてのテストを先に書いてからすべての実装を書く(水平スライシング)
  • 内部のコラボレーターをモックする代わりにパブリックインターフェースを通じてテストする
  • 動作ではなく実装の詳細を検証するテストを書く

よくある質問

TDDではいつテストを書くべきですか?
実装コードの前にテストを書いてください。テストは、構築する前に望む動作を定義します。
一度にいくつのテストを書くべきですか?
一度に1つのテストを書いてください。これにより、サイクルを小さく保ち、1つの動作に集中できます。
すべてをテストできない場合、何をテストすべきですか?
重要なパスと複雑なロジックに焦点を当ててください。アプリケーションにとってどの動作が最も重要かを確認してください。
自分のクラスやモジュールをモックすべきですか?
いいえ。外部API、データベース、ファイルシステムなどのシステム境界でのみモックしてください。独自のコードは реальных インターフェースを通じてテストするべきです。
TDDではいつリファクタリングすべきですか?
すべてのテストが通過したとき(緑の状態)でのみリファクタリングしてください。テストが失敗している間は絶対にリファクタリングしないでください。
自分のテストが良いかどうかをどうやって知りますか?
良いテストは、動作が壊れたときに壊れますが、内部リファクタリングには耐えられます。内部関数の名前変更でテストが壊れる場合、テストは動作ではなく実装をテストしていました。

開発者の詳細

作成者

mattpocock

ライセンス

MIT

参照

main

ファイル構成