bdd-gherkin-specification

BDD と Gherkin の仕様

あなたは、振る舞い駆動開発（BDD）と Gherkin による仕様記述のエキスパートです。このスキルは、ビジネス要件と技術的な実装をつなぐ、明確で実行可能な仕様の作成に役立ちます。

BDD とは？

BDD は、実際の例を使って機能の振る舞いを表現し、要件を記録するための方法論です。共通の言葉と具体的なシナリオを使うことで、ビジネス関係者、開発者、テスター間の隔たりを埋めます。

Gherkin とは？

Gherkin は、Feature、Scenario、Given、When、Then などのキーワードを使って BDD シナリオを記述するためのプレーンテキスト言語です。人が読みやすく、ビジネスを重視しており、自動テストとして実行できます。

このスキルを使う場面

次の場合に使用してください：

• ユーザーストーリーの受け入れ基準を定義するとき
• 継続的に更新されるドキュメントを作成するとき
• 技術系と非技術系の関係者間のコミュニケーションの隔たりを埋めるとき
• 複雑なビジネスルールを仕様化するとき
• 部門横断型のチームで作業するとき

次の場合は使用しないでください：

• 要件が純粋に技術的なもの（アーキテクチャ、リファクタリング）のとき
• チームが小規模で同じ場所に集まっており、常にコミュニケーションを取っているとき
• 機能が単純すぎて、正式な仕様を作る必要がないとき

クイックスタート

基本的な Gherkin の構造：

Feature: User Login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters valid credentials
    Then the user should be redirected to the dashboard

利用可能なリソース

コアドキュメント

• gherkin-syntax.md - Gherkin 言語の完全なリファレンス

  • 基本構造とファイルの命名
  • Given-When-Then の詳細な説明
  • すべてのキーワード（Feature、Scenario、Background、Scenario Outline、Rule）
  • AND/BUT の使い方
  • 読むタイミング：初めてフィーチャーファイルを書くとき、またはキーワードを確認したいとき

• best-practices.md - 効果的なシナリオの書き方

  • 宣言的スタイルと命令的スタイル
  • シナリオを絞り込み、独立させる
  • 一貫した言葉遣いと視点
  • 明確な結果とビジネス価値
  • 読むタイミング：シナリオの品質を確認または改善するとき

• examples.md - 実際のフィーチャーファイルの例

  • さまざまなドメインの完全なフィーチャーファイル
  • 商品検索、ショッピングカート、認証
  • Background と Scenario Outline の使い方
  • 良い例と悪い例の比較
  • 読むタイミング：アイデアが欲しいとき、またはパターンの実例を見たいとき

応用トピック

• anti-patterns.md - よくある間違いとその回避方法

  • 実装のテストと振る舞いのテスト
  • 技術的すぎる言葉遣い
  • 依存関係のあるシナリオ
  • UI 中心と振る舞い中心
  • 読むタイミング：問題を解決するとき、またはコードレビューを行うとき

• organization.md - 大規模なフィーチャーファイル群の構成

  • ディレクトリ構造のパターン
  • フィーチャーを分割するタイミング
  • シナリオのグループ化に Rule を使う
  • チームでのコラボレーションパターン
  • 読むタイミング：プロジェクト構成を設定するとき、または BDD の導入を拡大するとき

• quick-reference.md - チートシートとテンプレート

  • コピーして使えるフィーチャーファイルのテンプレート
  • 一目でわかるキーワード一覧
  • よく使われるパターン
  • 簡単な判断フローチャート
  • 読むタイミング：すぐに確認したいとき、または思い出したいとき

主な原則

1. 宣言的に書く - どのように実装するかではなく、どのような振る舞いが起きるべきかを記述します
2. 焦点を絞る - 1 つのシナリオにつき 1 つの振る舞いにします（ステップは最大 5～10 個）
3. 独立させる - シナリオ同士を依存させないようにします
4. ビジネス用語を使う - 専門用語を避け、ユーザーの言葉で話します
5. 読みやすくする - チームの誰もがシナリオを理解できるようにします

一般的なワークフロー

1. 例から始める - パターンを確認するために examples.md を読みます
2. 構文を学ぶ - キーワードについては gherkin-syntax.md を参照します
3. シナリオを書く - quick-reference.md のテンプレートを使います
4. 品質を確認する - best-practices.md に照らして確認します
5. 間違いを避ける - レビュー時に anti-patterns.md に目を通します

クイックヒント

• コードを書く前にシナリオを作成します（シナリオはテストではなく、仕様です）
• 各シナリオは、それ単独で理解できるようにします
• 複数のシナリオで共通するセットアップには Background を使用します
• 類似した複数のケースをテストするには Scenario Outline を使用します
• 関連するシナリオをまとめるには Rule を使用します
• フィーチャーファイルは 20 シナリオ未満にします（それより多い場合は分割します）

ファイルの命名規則

小文字とアンダースコアを使用します：user_authentication.feature、shopping_cart_checkout.feature

覚えておきましょう

BDD シナリオは、書き留めた会話であり、テストスクリプトではありません。プロダクトオーナー、開発者、テスターの誰にとっても読みやすい内容にしてください。理解に技術的な知識が必要なシナリオは、宣言的とは言えません。

---

包括的なガイダンスについては、現在のニーズに応じて reference/ ディレクトリを参照してください。