mcpField
T
tdd

tdd

github.com/dedalus-erp-pasテスト・品質111 回インストール
リポジトリ

tdd について

開発者向けのフレームワーク非依存型テスト駆動開発スキルです。実装の詳細ではなく公開インターフェースの振る舞いを検証し、段階的なレッド・グリーン・リファクタリングを促します。

主な機能

  1. 01公開インターフェースを基準にしたテスト
  2. 021サイクルで1つの振る舞いを検証
  3. 03テスト対象の計画と優先順位付け
  4. 04テスト合格後のリファクタリング
  5. 05各種テストフレームワークへの対応

活用シーン

  1. 01新機能のテスト作成開始
  2. 02振る舞いテストの段階的な追加
  3. 03動作を保ちながらのリファクタリング
  4. 04実装詳細に依存する脆いテストの回避

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dedalus-erp-pas/foundation-skills --skill tdd

インストール後、Claude Code で/tddを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

reference/
deep-modules.md
interface-design.md
mocking.md
refactoring.md
tests.md

詳細

テスト駆動開発

考え方

基本原則：テストでは実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証します。コードは全面的に変更される可能性がありますが、テストは変更されないようにします。

良いテストは、統合テストのように実際のコードパスを公開 API 経由で実行します。システムが「何を」するかを記述し、「どのように」するかは記述しません。良いテストは仕様書のように読めます。内部構造に依存しないため、リファクタリング後も機能します。

悪いテストは実装と密結合しています。内部の協調オブジェクトをモックしたり、プライベートメソッドをテストしたり、外部の手段で検証したりします。注意すべき兆候：振る舞いは変わっていないのに、リファクタリングするとテストが失敗します。

例についてはreference/tests.mdを、モックのガイドラインについてはreference/mocking.mdを参照してください。

フレームワークに依存しない設計

このスキルは、あらゆるテストフレームワーク（Vitest、Jest、Playwright、Cypress、pytest、JUnit など）およびあらゆるスタック（Vue.js、React、Node.js、バックエンドサービス）で利用できます。例はプロジェクトの言語やフレームワークに合わせて調整してください。

アンチパターン：水平スライス

すべてのテストを書いてから、実装をすべて書くのはやめてください。 これは「水平スライス」と呼ばれ、RED を「すべてのテストを書くこと」、GREEN を「すべてのコードを書くこと」として扱います。

この方法では、質の低いテストが生まれます。_想像上の_振る舞いをテストし、ユーザーに見える振る舞いではなく、物事の_形_をテストするため、実際の変更に対して鈍感になります。

正しいアプローチ：トレーサーバレットによる垂直スライスです。テストを 1 つ、実装を 1 つ行い、それを繰り返します。

WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3

ワークフロー

1. 計画

コードを書く前に：

  • 必要なインターフェースの変更をユーザーに確認する
  • テストする振る舞いを確認する（優先順位を付けてください。すべてをテストすることはできません）
  • ディープモジュール（小さなインターフェース、深い実装）の機会を特定する
  • テスト容易性を考慮してインターフェースを設計する
  • 実装手順ではなく、テストする振る舞いをリストアップする
  • 計画についてユーザーの承認を得る

次のように尋ねます：「公開インターフェースはどのような形にするべきですか？テストする上で、最も重要な振る舞いはどれですか？」

2. トレーサーバレット

エンドツーエンドで経路が機能することを証明するため、1 つのことを確認するテストを 1 つ書きます。

RED:   Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passes
3. 段階的なループ

残りの振る舞いについて、RED → GREENをテスト 1 つずつ繰り返します。

  • 現在のテストに合格するために必要な最小限のコードだけを書く
  • 将来のテストを先回りしない
  • 観察可能な振る舞いにテストの焦点を絞る
4. リファクタリング

すべてのテストに合格したら、リファクタリングの候補を探します。

  • 重複を抽出する
  • モジュールを深くする（複雑さをシンプルなインターフェースの背後に移す）
  • 自然な場合は SOLID 原則を適用する
  • 新しいコードから既存のコードについて何がわかるかを検討する
  • リファクタリングの各ステップの後にテストを実行する

RED の間はリファクタリングしないでください。 まず GREEN にしてください。

サイクルごとのチェックリスト

[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive an internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added

コメント

Markdown 対応