Gherkinを改善する方法はいくつかあります。

振る舞いを記述する

シナリオでは、システムの実装ではなく、システムの意図された振る舞いを記述する必要があります。言い換えれば、方法ではなく、何を記述する必要があります。

たとえば、認証シナリオの場合、次のように記述する必要があります。

When "Bob" logs in

代わりに

  Given I visit "/login"
  When I enter "Bob" in the "user name" field
    And I enter "tester" in the "password" field
    And I press the "login" button
  Then I should see the "welcome" page

最初の例、「ボブ」がログインするときは、機能要件です。2番目の、はるかに長い例は、手順の参照です。機能要件は機能ですが、手順は実装の詳細に属します。

そうすれば、機能の実装が変更された場合でも、舞台裏のプロセスステップのみを変更する必要があります。実装が変更されただけで、動作を変更する必要はありません。実際、フィーチャークローズを作成するときに自分自身に問いかけるべき良い質問は、「実装が変更された場合、この言葉遣いを変更する必要がありますか？」です。

答えが「はい」の場合は、実装固有の詳細を避けて、それを再調整する必要があります。副次的なメリットとして、結果として、シナリオははるかに短くなり、理解しやすくなります。

より宣言的なスタイルを検討する

シナリオをより保守しやすく、より壊れにくくするための1つの方法は、宣言的なスタイルを使用することです。宣言的なスタイルでは、実装の詳細ではなく、アプリケーションの動作を記述します。宣言的なシナリオは、「生きたドキュメント」としてより適切に読み取れます。宣言的なスタイルは、顧客が得ている価値に焦点を当てるのに役立ち、顧客が使用するキーストロークに焦点を当てるのに役立ちます。

命令的なテストは詳細を伝え、一部のコンテキストでは、このスタイルのテストが適切です。一方、現在のUIのメカニズムに密接に結び付いているため、保守にさらに多くの作業が必要になることがよくあります。実装が変更されるたびに、テストも更新する必要があります。

これは、命令的なスタイルの機能の例です

Feature: Subscribers see different articles based on their subscription level 

Scenario: Free subscribers see only the free articles
  Given users with a free subscription can access "FreeArticle1" but not "PaidArticle1" 
  When I type "freeFrieda@example.com" in the email field
  And I type "validPassword123" in the password field
  And I press the "Submit" button
  Then I see "FreeArticle1" on the home page
  And I do not see "PaidArticle1" on the home page

Scenario: Subscriber with a paid subscription can access "FreeArticle1" and "PaidArticle1"
  Given I am on the login page
  When I type "paidPattya@example.com" in the email field
  And I type "validPassword123" in the password field
  And I press the "Submit" button
  Then I see "FreeArticle1" and "PaidArticle1" on the home page  

各ステップは正確な指示です。入力と期待される結果は正確に指定されています。しかし、これらのテストを変更する必要があるアプリケーションへの変更を想像するのは簡単です。無料サブスクリプションと有料サブスクリプションで利用できるオプションは変更される可能性があります。ログインの手段さえ変わる可能性があります。将来、ユーザーが音声インターフェースまたは指紋でログインする場合はどうなりますか？

より宣言的なスタイルは、アプリケーションの機能がどのように実装されているかの詳細を隠します。

Feature: Subscribers see different articles based on their subscription level
 
Scenario: Free subscribers see only the free articles
  Given Free Frieda has a free subscription
  When Free Frieda logs in with her valid credentials
  Then she sees a Free article

Scenario: Subscriber with a paid subscription can access both free and paid articles
  Given Paid Patty has a basic-level paid subscription
  When Paid Patty logs in with her valid credentials
  Then she sees a Free article and a Paid article

宣言的なスタイルでは、各ステップがアイデアを伝えますが、正確な値は指定されていません。無料または有料の記事、さまざまなテストユーザーのサブスクリプションレベルなど、ユーザーがシステムとどのように対話するかの詳細（方法）は、ステップ定義（システムと対話する自動化コード）で指定されます。サブスクリプションパッケージは将来変更される可能性があります。ビジネスでは、このシナリオや同じステップ定義を使用する他のシナリオを変更することなく、無料プランと有料プランのサブスクライバーが利用できるコンテンツを変更できます。後で別のサブスクリプションレベルが追加された場合、そのシナリオを簡単に追加できます。「ボタンをクリックする」などの実装を示唆する用語を避けることで、シナリオはUIの実装の詳細に対してより回復力があります。実装が後で変更された場合でも、シナリオの意図は同じままです。さらに、シナリオに実装の詳細が多すぎると、それが示す意図された動作を理解するのが難しくなります。