ガーキン言語:構文、フォーマット、例
⚡ スマートサマリー
Gherkinは、実装の詳細を省略してソフトウェアの動作を記述する、ビジネスで読みやすい言語です。Given、When、Thenキーワードを使用して定義します。 Cucumber 平易な言葉で記述されたテストシナリオは、生きたドキュメントとして、また自動化されたBDDテストの骨組みとして機能する。

ガーキン言語とは何ですか?
ガーキン は、実装の詳細に立ち入ることなくビジネス動作を記述するのに役立つ、ビジネスで読みやすい言語です。これは、テストを定義するためのドメイン固有言語です。 Cucumber フォーマット。平易な言葉でユースケースを説明し、ユーザーが動作テストからロジックの詳細を削除できるようにする。
Gherkin形式のテキストは、ドキュメントとして、また自動テストの骨組みとして機能します。Gherkin形式は37以上の言語に存在するTreeTop Grammarに基づいているため、37以上の言語でGherkinを記述できます。このスクリプトには主に2つの目的があります。ユーザーシナリオを文書化すること、そして自動化されたBDDテストを作成するための基盤を提供することです。
なぜガーキンなのか?
共通の平易な言語フォーマットがないと、ビジネスチームと技術チームが要件を異なる方法で記述するため、誤解が生じます。Gherkinは、誰もが共通の構造化された語彙を使用できるようにすることで、通常の英語のように読みやすく、実行可能なテストに直接対応させることができます。
ガーキン構文
Gherkin は YAML と同様に行指向言語です。 Python各行はステップと呼ばれ、キーワードで始まります。インデントにはタブまたはスペースを使用します。コメントはどこにでも追加できますが、# 記号で始める必要があります。インタープリタは、Given、When、Then などの Gherkin キーワードを削除した後、各行を読み込みます。
Feature: Title of the Scenario Given [Preconditions or Initial Context] When [Event or Trigger] Then [Expected output]
Gherkinドキュメントは拡張子が.featureで、単に説明的な拡張子が付いたテストファイルです。 Cucumber Gherkinドキュメントを読み込み、テストを実行して、ソフトウェアがGherkin構文で記述されているとおりに動作するかどうかを検証します。
Gherkinで使用される重要な用語
主なキーワードは、特徴、背景、シナリオ、与えられた条件、いつ、次に、そして、しかし、およびシナリオの概要です。 Cucumber 厳密な命名規則はないが、明確な命名規則があると役立つ。
機能
ファイルの拡張子は .feature で、各フィーチャーファイルは 1 つのフィーチャーのみを記述する必要があります。Feature キーワードは以下で始まります。 特徴: スペースの後に機能名が続きます。
シナリオ
各フィーチャーファイルには複数のシナリオが含まれる場合があり、各シナリオは以下で始まります。 シナリオ: 続いてシナリオ名が続きます。
経歴
背景キーワードは、シナリオにコンテキストを追加します。すべてのシナリオで共有されるステップを含めることができますが、違いは、それらのステップが各シナリオの前に実行されることです。
与えられた
Givenキーワードは、ユーザーがシステムとのやり取りを開始する前に、システムを既知の状態にします。これは、前提条件またはコンテキストを定義します。
Given I am on "/."
Whenキーワードは、ユーザーが実行するアクションを定義します。
When I perform "Sign In."
その後
Thenキーワードは、Whenステップで実行されたアクションの後に観察される結果を定義します。目に見える変化のみを確認してください。
Then I should see "Welcome Tom."
そしてそしてしかし
Given、When、Then のステップは複数存在する場合があります。And および But キーワードは、可読性を高めるために追加のステップを追加します。
And I enter "EmailAddress" with "tomjohn@gmail.com." But I should see "Welcome Tom."
Given、When、Then、And、But はすべてテスト手順です。これらの順序を入れ替えてもインタープリタはエラーを発生させませんが、シナリオの読みやすさが損なわれるため、各キーワードは本来の目的に沿って使用してください。
ガーキンの例
例1: ソーシャルネットワーキングサイトのログイン機能。
Feature: Login functionality of a social networking site Given I am a registered user When I enter my username And I enter my password Then I should be redirected to the home page
Gherkinはフィーチャーファイルに記述された各ステップを解析するため、フィーチャーファイル内のステップはステップ定義ファイル内のステップと一致していなければなりません。
例2: 背景情報を含むユーザー認証シナリオ。
Feature: User Authentication Background: Given the user is already registered on the website Scenario: Successful login Given the user is on the login page When the user inputs the correct email address And the user inputs the correct password And the user clicks the Login button Then the user should be authenticated And the user should be redirected to their dashboard
Gherkinを使用する際のベストプラクティス
- 各シナリオはそれぞれ独立して実行されるべきです。
- すべての機能は、単独で実行可能であるべきである。
- 手順情報は個別に表示する必要があります。
- シナリオを要件と接続し、 track 各要件にどのシナリオが属するか。
- モジュール化された分かりやすい手順を作成し、よくあるシナリオを組み合わせる。
- システムが何をするのかを説明してください。どのように行うのかを説明する必要はありません。
ガーキンの利点
- Gherkinは、プログラマーでない人でも理解できるほどシンプルです。
- プログラマーはこれをテストを開始するための確固たる基盤として利用できる。
- これにより、ユーザーストーリーが理解しやすくなり、ビジネス要件に的確に対応できるようになります。
- ビジネス幹部も開発者も、同じ脚本を読むことができる。
- Gherkinのテストケースは、受け入れテストを自動テストに直接リンクします。
- この記述スタイルは、テスト間でコードを再利用しやすくする。
ガーキンのデメリット
- それには、高度なビジネス上の関与と協力が求められる。
- あらゆる状況でうまくいくとは限らない。
- 質の低いテストは、テストの保守コストを増加させる可能性がある。
