behavior-driven-development

振る舞い駆動開発（BDD）スキル

このスキルでは、コーディングタスクに振る舞い駆動開発の原則を適用するための包括的なガイドを提供します。BDDは単なるツールではなく、共通理解と高品質な実装を実現するための方法論です。

このスキルの使い方

ユーザーから機能追加、バグ修正、リファクタリングを依頼されたら、次の考え方を適用してください。

1. まず振る舞いを理解する： システムが何をするべきかを把握するまでは、コーディングを始めないでください。
2. シナリオを定義する： 期待される振る舞いを具体例（Gherkin）にして作成するか、ユーザーに尋ねてください。
3. テスト主導で実装する： Red-Green-Refactorサイクルを使ってください。

主な概念

1. BDDサイクル

プロセスは要件からコードへと進みます。

• 発見： 具体例を通じて要件を明確にします（「Three Amigos」）。
• 定式化： これらの例を具体的なシナリオ（Given/When/Then）として記述します。
• 自動化： TDDを使って実装します。

詳しいガイドについては、./references/bdd-best-practices.mdを参照してください。

2. シナリオの記述（Gherkin）

シナリオは「実行可能な仕様」です。

• 宣言的な記述にします（ビジネス上の関心事を重視）。
• 技術用語やUIの詳細は避けます。
• 1つのシナリオにつき、1つの振る舞いを記述します。
• superpowersワークフローでは、計画段階のシナリオ一覧としてbdd-specs.mdを使用します。ブレインストーミングと計画書の作成時には、レビュー済みのGiven/When/Thenシナリオをdocs/plans/.../bdd-specs.mdに記録し、設計レビュー、タスクの分解、スプリントの契約がすべて同じ情報源を参照できるようにしてください。
• 実行可能なシナリオはコードコメントではなく、.featureファイルに保存します — 実装を始めたら、自動化するシナリオを.featureファイル、またはフレームワーク標準の実行可能なテスト形式に変換します。bdd-specs.mdは設計と計画に使用し、.featureファイルは自動化と生きたドキュメントに使用します。

構文と保存構造については、./references/gherkin-guide.mdを参照してください。

3. Red-Green-Refactor（TDD）

実装の原動力となるプロセスです。

1. RED： シナリオ（またはその一部分）の失敗するテストを書きます。
2. GREEN： テストを通すために必要最小限のコードを書きます。
3. REFACTOR： テストを通したまま、コードを整理します。

重要：鉄則

「失敗するテストを先に書かずに、本番コードを書いてはいけません。」

実装コードを書く前に、Redの段階でテストが正しい理由で失敗することを必ず確認してください（テストを実行し、失敗の出力を読む）。この段階を省略したり、もっともらしい理由をつけて避けたりすると、次のような問題が生じます。

1. テストが偶然通ってしまう — テストが失敗する能力を備えているかどうか判断できません。
2. 実装に偏ったテストになる — 契約で定められた振る舞いではなく、書かれたコードを反映したテストになります。
3. 初日からレガシーコードになる — 将来のリグレッションを検出する振る舞いのセーフティネットがありません。

すでに本番コードがある場合

そのコードを削除し、失敗するテストから導き直してください。「参考として」残したり、テストファースト版に「適応」させたり、テストを書いている間に読んだりしてはいけません。いずれも、テスト対象のコードを見ながら書いたテストは、適切な内容を検証しているかどうかにかかわらず最初から通ってしまうという、前述の実装偏重テストの問題をひそかに再発させます。削除とは、削除することです。

よくある正当化（すべて退けてください）

正当化	成り立たない理由
「テストは後で書けばいい。どちらにしてもカバレッジは同じだ」	動作するコードに対して書いたテストは、初回実行で必ずパスします。それで証明できるのは、テストがクラッシュしないことだけであり、正しい動作を検証していることではありません。明示した理由で最初に失敗したテストだけが、リグレッションを検出できることを示せています。
「手動で動作することはすでに確認した」	手動での確認は再現できず、リグレッションを防ぐ仕組みも残りません。「一度動作したか」には答えますが、「今後も動作し続けるか」には答えません。
「単純すぎるのでテストは不要だ」	単純なコードも複雑なコードと同じように、動作が変わることがあります。鉄則に複雑さによる例外はありません。以下に挙げる3つの例外のみがあり、それ以外はありません。
「TDD を教条的ではなく、実用的に進める」	これは正当化であり、別の選択肢ではありません。この表の項目はいずれも、Red のステップを省略することを「実用的」だと考えた結果です。
「すでに1時間かけたのに、削除するのは無駄だ」	サンクコストです。コードを削除しても残しても、かけた1時間はすでに過ぎています。テストされていないコードを残しても、その1時間を取り戻せるわけではなく、未検証のリグレッションリスクが上乗せされるだけです。

正当な例外は ./references/bdd-best-practices.md に記載されたもの（使い捨てのプロトタイプ、生成コード、設定ファイル）だけです。それらについても、黙って例外だと決めつけず、ユーザーに確認してください。

後から書いたテストが答えるのは別の問いです

テストファーストのテストは、「システムが満たすべき契約はこれだ」と表します。後から書くテストは、「すでに書いたコードがたまたまこう動作する」と表します。独立した仕様に合わせるのではなく、その動作に合わせて作られているため、コードの動作が間違っていてもパスします。すでに見えているコードを対象にテストを書こうとしていることに気づいたら、いったん止めてコードを削除し、コードではなく 動作 に対するテストを書いてください。

参考資料

• ./references/bdd-best-practices.md - BDD の方法論、発見、定式化、自動化
• ./references/gherkin-guide.md - Gherkin シナリオの構文、保存構造、例
• ./references/testing-anti-patterns.md - モックの落とし穴や、実際の動作を検証せずにテストがパスするその他の原因