Gherkin入門

2026年7月31日

はじめに

このドキュメントは、Gherkin（ガーキン）の基本的な構文・キーワード・書き方を体系的に学ぶための入門書です。実際の.featureファイルの例を通じて、実践的な書き方を理解することを目的としています。

第1章: Gherkinとは何か

1.1 Gherkinの概要

Gherkin は、ソフトウェアの振る舞いを記述するための言語です。Cucumberプロジェクトによって開発され、構造化された自然言語（主に英語）を使って、テストの仕様を記述します。

Gherkinの最大の特徴は、技術的な詳細を最小限に抑え、ビジネスの文脈で仕様を記述できる点です。これにより、開発者、QA、ビジネス担当者（プロダクトオーナー等）が同じ言語で対話することができます。

1.2 振る舞い駆動開発（BDD）との関係

Gherkinは、振る舞い駆動開発（Behavior-Driven Development: BDD） のための仕様記述言語です。

BDDとは、テスト駆動開発（TDD）を発展させた開発手法で、「ソフトウェアがどのような振る舞いをするべきか」に焦点を当てます。

観点	テスト駆動開発（TDD）	振る舞い駆動開発（BDD）
誰が書くか	開発者	開発者・QA・ビジネス担当者
何に焦点か	技術的正しさ	ビジネス価値
言語	実装言語	自然言語（Gherkin）
出力	テストコード	実行可能仕様

BDDはTDDに「仕様記述の言語」と「三者協業」を加えたものです。Gherkinは、この「振る舞い」を記述するための手段を提供します。

BDDの考え方:
  1. 振る舞いを仕様として記述（Gherkin）
  2. 仕様を自動テストとして実行（Cucumber等）
  3. 仕様と実装のギャップを解消

1.3 なぜGherkinを使うのか

Gherkinを使う主なメリットは以下の通りです：

共通言語の確立: 開発者、QA、ビジネス担当者が同じ文脈で話せる
実行可能仕様: 記述した仕様がそのままテストとして実行できる
仕様の明確化: 曖昧な要件を具体的な例で明確にできる
ドキュメントとしての価値: 仕様書が常に最新の状態に保たれる
リファクタリングの安全網: 仕様の変更が即座にテスト失敗として検知できる

1.4 `.feature`ファイルの基本的な構造

Gherkinで記述されたファイルは、通常 .feature 拡張子を持ちます。基本的な構造は以下の通りです：

Feature: 機能の説明

  シナリオの説明を書くこともできます

  Scenario: シナリオの名前
    Given 初期状態の記述
    When アクションの記述
    Then 期待される結果の記述

Feature: で始まる行が、そのファイルが記述する機能を示します
Scenario: で始まる行が、具体的なテストケースを示します
Given, When, Then で始まる行が、それぞれ事前条件、アクション、結果を示します

1.5 振る舞いを記述する（what, not how）

Gherkinの最も重要な原則の一つは、システムの振る舞い（what）を記述することです。実装方法（how）を記述してはいけません。

例えば、認証のシナリオを考えると：

# 良い例: 振る舞いを記述（what）
Scenario: ユーザーがログインする
  When "Bob" がログインする
  Then "ようこそ" ページが表示される

# 避けるべき: 実装を記述（how）
Scenario: ユーザーがログインする
  Given "http://example.com/login" にアクセスする
  When "user name" フィールドに "Bob" を入力する
  And "password" フィールドに "tester" を入力する
  And "ログイン" ボタンを押す
  Then "welcome" ページが表示される

最初の例は機能的な要件を記述しています。2番目の例は手続き的な参照になっています。

判断基準: 「実装が変わったら、この記述も変える必要があるか？」

この質問に「Yes」と答える場合は、実装の詳細を避けて書き直す必要があります。実装が変わっても、振る舞い自体は変わらないはずです。

1.6 宣言的スタイルと命令的スタイル

Gherkinのシナリオには、2つの書き方があります。

命令的スタイル（Imperative）

命令的スタイルは、具体的な手順や操作を記述します：

Feature: サブスクライバーは契約レベルに応じて異なる記事を見る

  Scenario: フリー契約者はフリー記事のみを見る
    Given フリー契約のユーザーがいる
    When メールフィールドに "freed@email.com" を入力する
    And パスワードフィールドに "validPassword123" を入力する
    And "送信" ボタンを押す
    Then ホームページに "FreeArticle1" が表示される
    And ホームページに "PaidArticle1" が表示されない

各ステップは正確な指示です。入出力が具体的に指定されています。しかし、実装が変わればテストも変更する必要が出てきます。

宣言的スタイル（Declarative）

宣言的スタイルは、アプリケーションの振る舞いを記述します：

Feature: サブスクライバーは契約レベルに応じて異なる記事を見る

  Scenario: フリー契約者はフリー記事のみを見る
    Given フリー契約のフリー・フリーダがいる
    When フリー・フリーダが有効な認証情報でログインする
    Then フリー記事が表示される

宣言的スタイルでは、各ステップがアイデアを伝えます。正確な値は指定されません。ユーザーがシステムとどのように対するかなどの詳細は、step definition（自動テストコード）に隠蔽されます。

宣言的スタイルのメリット：

実装の詳細に依存しないため、変更が弱い
「 living documentation（生きたドキュメント）」として読みやすい
クライアントが得る価値に焦点を当てられる
実装が変わってもシナリオの内容は変わらない

命令的スタイルも文脈によっては適切ですが、UIの仕組みに密接に結びついているため、実装が変わるたびにテストを更新する必要があり、メンテナンスコストが高くなります。

第2章: 基本的な構文

2.1 `.feature`ファイルの構造

.featureファイルは、以下の要素で構成されます：

Feature: 機能名
  機能の説明（省略可能）

  Scenario: シナリオ名
    Given 事前条件
    When アクション
    Then 結果

  Scenario: 別のシナリオ名
    Given 別の事前条件
    When 別のアクション
    Then 別の結果

2.2 主要キーワード一覧

Gherkinでは、以下の主要キーワードが定義されています：

キーワード	役割	備考
`Feature:`	機能の説明	必須、ファイルの先頭に1つだけ
`Scenario:` / `Example:`	具体的なテストケース	複数可能
`Given`	事前条件（初期状態）	初期状態を記述
`When`	アクション（イベント）	ユーザー操作やシステムイベント
`Then`	結果（期待値）	観測可能な出力を記述
`And`	接続詞	直前のキーワードの継続
`But`	接続詞	直前のキーワードの継続（否定や対比）
`*`	アスタリスク	`Given`/`When`/`Then`/`And`/`But` の代用

2.3 記述ルール

# で始まる行はコメントとして扱われます：

Feature: 単語当てゲーム

  # これはコメントです。テスト実行時には無視されます。
  Scenario: 作成者がゲームを始める
    When 作成者がゲームを始める
    # この行もコメント
    Then 作成者は参加者を待つ

インデント

Gherkinでは、スペースとタブの両方がインデントに使用できますが、2スペースのインデントが推奨されます：

Feature: ブログ投稿
  # 2スペースインデントが推奨

  Scenario: 投稿する
    When ブログに投稿する
    Then 投稿が公開される

説明文

Feature:, Scenario:, Background:, Rule: の直後に、自由な説明文を書くことができます。これらの説明文はテスト実行時には無視されますが、Cucumber HTML Formatterなどのレポートツールで表示・活用されます：

Feature: 単語当てゲーム

  2人のプレイヤーが参加するターン制のゲームです。
  作成者が単語を選び、当てる側がそれを推測します。
  当てる側が作成者の単語を当てたらゲーム終了です。

  Scenario: ゲーム開始
    When 作成者がゲームを始める
    Then 当てる側が参加するのを待つ

説明文ではMarkdown形式もサポートされています。

2.4 コロンの有無の注意点

Gherkinのキーワードには、コロンの後についているものとついていないものがあります。これを間違えると、テストが実行されなくなります。

コロンが必要なキーワード:

Feature:
Scenario: / Example:
Background:
Rule:
Scenario Outline: / Scenario Template:
Examples: / Scenarios:

コロンが不要なキーワード:

Given
When
Then
And
But
*

# 正しい書き方
Feature: 単語当てゲーム
  Scenario: ゲーム開始
    Given ゲームが準備できている
    When 作成者がゲームを開始する
    Then 参加者が待機中になる

# 間違い: Given, When, Thenにはコロン不要
# Given: ゲームが準備できている  ← これは無視される！

第3章: Given-When-Thenの書き方

3.1 Given: 初期状態の記述

Given は、シナリオの初期状態（事前条件）を記述します。システムがどのような状態で始まるかを定義します。

Givenの役割: システムを既知の状態に配置する

Scenario: 銀行口座の残高照会
  Given 口座の残高が430ポンドである
  When 残高を確認する
  Then 残高が430ポンドと表示される

Givenの例:

Given ユーザーAとしてログインしている
Given 商品が在庫10個ある
Given 3人のプレイヤーが参加している

注意点:

Givenにはユーザーの操作ではなく、状態を記述する
複数のGivenがある場合は、2つ目以降にAndを使うと読みやすくなる

Scenario: ブログ投稿
  Given "ユーザーA"としてログインしている
  And "ブログA"が存在する
  And "ブログA"に3件の投稿がある
  When "ブログA"に新しい投稿をする
  Then 投稿が公開される

3.2 When: アクションの記述

When は、システムに対して行われるアクション（イベント）を記述します。ユーザーの操作や、外部システムからのイベントなどを表します。

Whenの役割: システムに対するイベントやアクションを記述する

Scenario: 商品購入
  Given カートに商品が3個入っている
  When 購入ボタンを押す
  Then 購入完了画面が表示される

Whenの例:

When 商品を検索する
When 会員登録をする
When 期限が過ぎる

注意点:

Whenには具体的な操作を記述する
技術的な詳細（「ボタンをクリック」等）ではなく、ユーザーの意図を記述する
例: 「ボタンをクリックする」ではなく「商品を検索する」

3.3 Then: 期待される結果の記述

Then は、アクション実行後に期待される結果を記述します。これは観測可能な出力であるべきです。

Thenの役割: システムの期待される振る舞いを記述する

Scenario: 商品検索
  Given 商品カタログに100件の商品がある
  When "ノートパソコン"を検索する
  Then 関連商品が5件表示される

Thenの例:

Then 商品が5件表示される
Then エラーメッセージが表示される
Then メールが送信される

注意点:

Thenには観測可能な結果を記述する
データベース内の直接の変更ではなく、ユーザーに見える結果を記述する
例: 「データベースにレコードが追加される」ではなく「確認メッセージが表示される」

3.4 And/But: 接続詞としての使い方

And と But は、直前のキーワードの継続を示すために使います。可読性を高める効果があります。

Scenario: 複数条件のテスト
  Given 口座に1000円入っている
  And 限度額が5000円である
  When 3000円を引き出す
  Then 残高が7000円になる
  And 取引履歴に記録される

And: 直前の条件/アクション/結果の追加
But: 直前の条件/アクション/結果との対比や例外

Scenario: 制限のテスト
  Given 年齢が18歳未満である
  When 会員登録をする
  Then 登録が拒否される
  But 管理者は登録できる

3.5 *: アスタリスク表記

* は、Given, When, Then, And, But のいずれのキーワードの代わりにも使えます。リスト形式の記述に便利です。

Scenario: お買い物体験
  Given お出かけ中
  * 卵を持っている
  * 牛乳を持っている
  * バターを持っている
  When ショッピングリストを確認する
  Then 何も買うものがない

この場合、* は Given の継続として扱われます。

3.6 ステップ数の推奨

各シナリオのステップ数は3-5ステップが推奨されます。

少なすぎると: テストの目的が不明確になる
多すぎると: 可読性が下がり、保守が難しくなる
3-5ステップ: 適切な粒度でテストの意図が伝わる

長いシナリオが必要な場合は、Background（第5章）やScenario Outline（第6章）を検討しましょう。

第4章: ベストプラクティス

4.1 ドメイン言語の重要性

Gherkinで重要なのは、ドメイン言語（その業界・ドメイン特有の言葉）を使うことです。技術用語や実装の詳細ではなく、ビジネスの文脈で使われる言葉で記述します。

# 良い例: ドメイン言語
Feature: 銀行口座
  Scenario: 入金
    Given 口座の残高が10000円である
    When 5000円を入金する
    Then 残高が15000円になる

# 避けるべき: 技術用語
Feature: 銀行口座
  Scenario: 入金処理
    Given account.balance = 10000
    When call deposit(5000)
    Then assert account.balance == 15000

4.2 技術詳細を隠蔽する

Gherkinの仕様には、技術的な実装の詳細は含めません。実装の詳細は、step definition（実装コード）に隠蔽します。

# 良い例: ユーザーの視点
  When 商品を検索する
  Then 関連商品が表示される

# 避けるべき: UIの詳細
  When 検索ボックスに"ノートPC"を入力してEnterを押す
  Then 検索結果リストに5件表示される

4.3 「1922年想像」の原則

Gherkinの仕様を記述する際、「1922年にいたつもりで」と想像してみてください。1922年にはコンピュータもインターネットもありません。その前提で、どのように仕様を記述するかを考えます。

この原則により、技術に依存しない、普遍的な仕様が書けるようになります。

# 1922年想像: 手動で処理を想像
Feature: メール送信
  Scenario: メールを送信する
    Given 差出人と宛先が指定されている
    And 本文が書かれている
    When 送信を依頼する
    Then 宛先にメールが届く

4.4 よくあるミスと回避方法

コロンの誤用

第2.4章で解説した通り、キーワードによるコロンの有無が異なります：

# 誤り: Givenにコロンをつけている
  Given: 残高が1000円である  ← 無視される！

# 正しい
  Given 残高が1000円である

重複ステップ

Gherkinでは、キーワードを除くステップのテキストが重複すると、エラーになります：

# 誤り: 重複するステップ
  Given 残高が1000円である
  Then 残高が1000円である  ← これは重複とみなされる！

# 正しい: 明確に区別する
  Given 口座に1000円が入っている
  Then 残高は1000円と表示される

4.5 レビューチェックリスト

Gherkinの仕様を書く際、以下の点をチェックしましょう：

読みやすさ: ドメインの専門家でなくても理解できるか
一貫性: 用語の使い方が統一されているか
正確性: 仕様が正確に記述されているか
具体性: 曖昧な表現が含まれていないか
適切な粒度: ステップ数が3-5程度か
技術非依存: UIや実装の詳細が含まれていないか

第5章: Background

5.1 Backgroundの役割

Background は、複数のシナリオで共通の事前条件を記述するための機能です。各シナリオの先頭に同じGivenステップを繰り返す必要がなくなります。

Feature: ブログ投稿

  Background:
    Given "ユーザーA"としてログインしている
    And "ブログA"が存在する

  Scenario: 投稿する
    When "ブログA"に投稿する
    Then 投稿が公開される

  Scenario: 下書き保存
    When "ブログA"を下書き保存する
    Then 下書きが保存される

5.2 使用タイミング

Background は、同じFeature内の全シナリオで共通の事前条件がある場合に使用します。Backgroundに記述されたGivenステップは、各シナリオの実行前に自動的に実行されます。

5.3 Background のベストプラクティス

Background は便利な機能ですが、使いすぎには注意が必要です。

Background に複雑な状態を記述しない

Background は共通の事前条件を記述するための機能ですが、複雑な状態のセットアップには使わないほうが良いです：

# 避けるべき: Background に複雑な状態
  Background:
    Given ユーザーAが作成したブログAがある
    And ユーザーBが作成したブログBがある
    And 管理者Cがいる
    And 3件の記事がブログAにある
    And 5件の記事がブログBにある
    ... 長くなる

# 良い: 高レベルのステップを使う
  Background:
    Given サイトに管理者と一般ユーザーがいる
    And 各ユーザーがブログを持っている

短い Background の重要性

Background は短く保つことが重要です。以下の点を意識しましょう：

4行以内を目安にする
クライアントがシナリオを読む際に Background を覚えておく必要がある
Background が長すぎると、シナリオの意味が分かりにくくなる

具体的で記憶に残る記述

Background は具体的で記憶に残る名前を使うと良いでしょう：

# 良い例: 具体的な名前
  Background:
    Given "Alice"という管理者がいる
    And "Bob"というユーザーがいる

# 避けるべき: 抽象的な名前
  Background:
    Given "Admin A"がいる
    And "User B"がいる

人間の脳はストーリーを覚えるのが得意です。抽象的な名前（“User A”, “Site 1”など）よりも、具体的な名前を使う方がシナリオの意味をより理解しやすくなります。

5.4 Background の例

Feature: ブログ投稿

  ブログ所有者のみが自分のブログに投稿できます。ただし、管理者は
  すべてのブログに投稿できます。

  Background:
    Given グローバル管理者 "Greg" がいる
    And "Greg's anti-tax rants" というブログがある
    And "Dr. Bill" というユーザーがいる
    And "Dr. Bill" が所有する "Expensive Therapy" というブログがある

  Scenario: Dr. Bill が自分のブログに投稿
    Given Dr. Bill としてログインしている
    When "Expensive Therapy" に投稿する
    Then "Your article was published." と表示される

  Scenario: Dr. Bill が他人のブログに投稿しようとして失敗
    Given Dr. Bill としてログインしている
    When "Greg's anti-tax rants" に投稿する
    Then "Hey! That's not your blog!" と表示される

第6章: Scenario Outline

6.1 Scenario Outlineの役割

Scenario Outline は、同じシナリオを異なるデータで複数回実行するための機能です。類似したシナリオを1つにまとめて記述できます。

Scenario Outline: きゅうりを食べる
  Before <start>本あるきゅうりを食べる
  When <eat>本食べる
  Then <left>本残る

  Examples:
    | start | eat | left |
    |    12 |   5 |    7 |
    |    20 |   5 |   15 |

6.2 テンプレート構文

<パラメータ名> 形式でプレースホルダを記述します。このパラメータは、後続のExamplesテーブルの値で置換されます。

Scenario Outline: 商品の割引

  Given 商品の価格が<price>円である
  When <discount>%の割引をする
  Then 最終価格が<final_price>円になる

  Examples:
    | price | discount | final_price |
    |  1000 |    10    |     900     |
    |  2000 |    20    |    1600     |
    |   500 |     5    |     475     |

6.3 Examplesテーブル

Examplesテーブルは、パラメータに設定する値の組み合わせを定義します。

1行目はヘッダ（パラメータ名）
2行目以降がデータ
各データ行が1回のシナリオ実行に対応

Scenario Outline: 引き算のテスト
  Given <a>がある
  When <b>を引く
  Then <result>が残る

  Examples:
    | a | b | result |
    | 5 | 3 |    2   |
    | 10| 4 |    6   |
    | 8 | 8 |    0   |

6.4 パラメータの使用方法

パラメータは以下の場所で使用できます：

シナリオの説明
ステップのテキスト
Data Tables（第7章参照）
Doc Strings（第7章参照）

Scenario Outline: "<user>"のログインテスト

  Given "<user>"としてログインしている
  When "<page>"にアクセスする
  Then "<message>"が表示される

  Examples:
    | user  | page       | message              |
    | admin | ダッシュボード | 管理画面が表示される |
    | user1 | プロフィール | プロフィールが表示される |

6.5 Scenario Outlineの例

Scenario Outline: eating cucumbers

  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |    12 |   5 |    7 |
    |    20 |   5 |   15 |

第7章: Data TablesとDoc Strings

7.1 Data Tables: 構文

Data Tablesは、表形式のデータをステップに渡すための機能です。|（パイプ）でセルを区切ります。

Feature: ユーザー管理

  Scenario: ユーザーを一括作成
    Given 以下のユーザーが存在する:
      | name   | email              |
      | 山田   | yamada@example.com |
      | 鈴木   | suzuki@example.com |
      | 高橋   | takahashi@example.com |

7.2 セル内のエスケープ

Data Tablesのセル内で特殊文字を使う場合、以下のエスケープシーケンスを使用します：

エスケープ	意味
`\n`	改行
`\\|`	パイプ記号
`\\`	バックスラッシュ

Feature: テキスト処理

  Scenario: 特殊文字のテスト
    Given 以下のテキストがある:
      | content        |
      | 複数行\nのテキスト |
      | パイプ\|記号     |
      | バックスラッシュ\\ |

7.3 Data Tablesの例

Feature: 商品管理

  Scenario: 商品を一括登録
    Given 以下の商品が存在する:
      | name    | price | stock |
      | ノートPC | 98000 |    10 |
      | マウス   |  3500 |   100 |
      | キーボード |  8500 |    50 |

  Scenario: 在庫チェック
    When 各商品の在庫を確認する
    Then 以下の在庫数が表示される:
      | name    | stock |
      | ノートPC |    10 |
      | マウス   |   100 |
      | キーボード |    50 |

7.4 Doc Strings: 構文

Doc Stringsは、複数行のテキストをステップに渡すための機能です。"""（トリプルクォート）または ```（バックティック）で囲みます。

Feature: ブログ投稿

  Scenario: Markdown投稿
    Given "タイトル"という名前のブログ投稿
    And 以下のMarkdown本文:
      """
      # はじめに

      ここに本文を書きます。
      """

7.5 コンテンツタイプの指定

Doc Stringsには、コンテンツのタイプを指定できます。""" の直後にタイプ名を記載します：

Feature: ブログ投稿

  Scenario: HTML投稿
    Given 以下のHTML本文:
      """html
      <h1>タイトル</h1>
      <p>本文の内容</p>
      """

  Scenario: JSONデータ
    Given 以下のJSONデータ:
      """json
      {
        "name": "山田",
        "age": 30
      }
      """

コンテンツタイプを指定することで、エディタのシンタックスハイライトが有効になる場合があります。

7.6 Doc Stringsの例

Feature: ブログ投稿

  Scenario: Markdown投稿
    Given "Random"という名前のブログ投稿
    And 以下のMarkdown本文:
      """
      Some Title, Eh?
      ===============

      Here is the first paragraph of my blog post.
      """

第8章: Ruleと言語指定

8.1 Ruleの役割

Rule は、ビジネスルールをグループ化するための機能です。

Ruleを使うと、関連するシナリオを論理的にグループ化できます：

Feature: 高齢者割引

  Rule: 65歳以上のユーザーは10%割引

    Scenario: 65歳のユーザー
      Given 年齢が65歳である
      When 商品を購入する
      Then 10%の割引が適用される

    Scenario: 64歳のユーザー
      Given 年齢が64歳である
      When 商品を購入する
      Then 割引は適用されない

  Rule: 会員は5%割引

    Scenario: 会員
      Given 会員である
      When 商品を購入する
      Then 5%の割引が適用される

8.2 RuleとBackground

RuleにもBackgroundを記述できます。Rule内の全シナリオに共通の事前条件を記述します：

Feature: 期限切れタスクの通知

  Rule: ユーザーは1日の最初の利用時に期限切れタスクの通知を受ける
    Background:
      Given 期限切れのタスクがある

    Scenario: 1日の最初の利用
      Given 昨日最後にアプリを使用した
      When アプリを使用する
      Then 期限切れタスクの通知を受ける

    Scenario: 既にその日に使用済み
      Given 今日既にアプリを使用した
      When アプリを使用する
      Then 期限切れタスクの通知を受けない

8.3 `# language:` ディレクティブ

Gherkinファイルの先頭に# language: ディレクティブを記載すると、そのファイルで使用される言語を指定できます：

# language: ja
フィーチャー: 単語当てゲーム

  シナリオ: 作成者がゲームを始める
    もし 作成者がゲームを開始したら
   ならば 作成者は参加者を待つ

Gherkinは70以上の言語に翻訳されています。日本語では以下のキーワードが使えます：

英語	日本語
Feature	フィーチャー
Scenario	シナリオ
Given	前提
When	もし
Then	ならば
And	そして
But	しかし

ただし、実務では英語キーワードを使うのが一般的です。日本語キーワードを使う場合は、チーム内で統一することが重要です。

8.4 言語選択の注意点

Gherkinで使う言語は、ユーザーやドメイン専門家が使う言語と一致させるべき
2つの言語間で翻訳することは避ける
英語キーワードを使う場合、# language: ディレクティブは不要（デフォルトが英語）

第9章: まとめ

9.1 基本テンプレート

# language: en

Feature: 機能の説明

  機能の詳細な説明（省略可能）

  Background:
    Given 共通の事前条件1
    And 共通の事前条件2

  Scenario: シナリオ1
    Given 事前条件1
    And 事前条件2
    When アクション
    Then 結果1
    And 結果2

  Scenario: シナリオ2
    Given 別の事前条件
    When 別のアクション
    Then 別の結果

  Scenario Outline: パラメータ化されたシナリオ
    Given <パラメータ1>がある
    When <パラメータ2>をする
    Then <結果>が得られる

    Examples:
      | パラメータ1 | パラメータ2 | 結果 |
      | 値1         | 値A         | 結果1 |
      | 値2         | 値B         | 結果2 |

9.2 キーワードクイックリファレンス

キーワード	用途	コロン
`Feature:`	機能の説明	必要
`Scenario:`	テストケース	必要
`Given`	事前条件	不要
`When`	アクション	不要
`Then`	結果	不要
`And`	接続詞	不要
`But`	接続詞（対比）	不要
`*`	任意のステップ	不要
`Background:`	共通事前条件	必要
`Scenario Outline:`	パラメータ化シナリオ	必要
`Examples:`	テーブルデータ	必要
`Rule:`	ビジネスルール	必要

9.3 よく使うパターン

データテーブルを使う場合:

  Given 以下のデータがある:
    | key | value |
    | a   | 1     |
    | b   | 2     |

Doc Stringsを使う場合:

  Given 以下の内容:
    """
    複数行のテキスト
    ここに続く
    """

参考文献

Cucumber Gherkin Reference - 公式リファレンス
Cucumber 公式ドキュメント - 総合的なドキュメント

PENGUINITIS

Gherkin入門

はじめに

第1章: Gherkinとは何か

1.1 Gherkinの概要

1.2 振る舞い駆動開発（BDD）との関係

1.3 なぜGherkinを使うのか

1.4 .featureファイルの基本的な構造

1.5 振る舞いを記述する（what, not how）

1.6 宣言的スタイルと命令的スタイル

命令的スタイル（Imperative）

宣言的スタイル（Declarative）

第2章: 基本的な構文

2.1 .featureファイルの構造

2.2 主要キーワード一覧

2.3 記述ルール

コメント

インデント

説明文

2.4 コロンの有無の注意点

第3章: Given-When-Thenの書き方

3.1 Given: 初期状態の記述

3.2 When: アクションの記述

3.3 Then: 期待される結果の記述

3.4 And/But: 接続詞としての使い方

3.5 *: アスタリスク表記

3.6 ステップ数の推奨

第4章: ベストプラクティス

4.1 ドメイン言語の重要性

4.2 技術詳細を隠蔽する

4.3 「1922年想像」の原則

4.4 よくあるミスと回避方法

コロンの誤用

重複ステップ

4.5 レビューチェックリスト

第5章: Background

5.1 Backgroundの役割

5.2 使用タイミング

5.3 Background のベストプラクティス

Background に複雑な状態を記述しない

短い Background の重要性

具体的で記憶に残る記述

5.4 Background の例

第6章: Scenario Outline

6.1 Scenario Outlineの役割

6.2 テンプレート構文

6.3 Examplesテーブル

6.4 パラメータの使用方法

6.5 Scenario Outlineの例

第7章: Data TablesとDoc Strings

7.1 Data Tables: 構文

7.2 セル内のエスケープ

7.3 Data Tablesの例

7.4 Doc Strings: 構文

7.5 コンテンツタイプの指定

7.6 Doc Stringsの例

第8章: Ruleと言語指定

8.1 Ruleの役割

8.2 RuleとBackground

8.3 # language: ディレクティブ

8.4 言語選択の注意点

第9章: まとめ

9.1 基本テンプレート

9.2 キーワードクイックリファレンス

9.3 よく使うパターン

参考文献

1.4 `.feature`ファイルの基本的な構造

2.1 `.feature`ファイルの構造

8.3 `# language:` ディレクティブ