はい、実際のシナリオで必要な場合、Gherkin シナリオでは複数のWhen/サイクルが適切です。Then
SaxonMatt の回答は、シナリオは UI 操作の言語ではなく利害関係者の言語で記述するのが最適であり、そうすることでシナリオの長さを短縮できることが多いという優れた点を示していますが、それでは質問の正確なポイントを見逃しています。角で雄牛を取りましょう。
Gherkin は受け入れテスト用に設計されています。つまり、利害関係者レベルの要件が完全に実装されていること、つまりソフトウェアが実際に利害関係者に価値を提供することをテストするテストです。価値を提供するには、複数の行動と反応のサイクルが必要な場合があります。次のシナリオを検討してください。
Scenario: Guest buys a product
# This scenario starts with the user not logged in, which doesn't require a step
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
Then I should see 1 product in my shopping cart
When I request to check out
Then I should see the account creation form
When I create an account
Then I should see the checkout form with 1 product, "Elliptical Juicer"
When I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
(シナリオに複数のWhen/Thenサイクルがある場合は、目立つように空白行で区切るのが好きです。)
Whenこのシナリオが複数の/Thenサイクルで最適に記述される理由はいくつかあります。
ユーザーがチェックアウトする前に、ショッピング カートに 1 つの製品が表示されます (サイト ヘッダーの数字としてのみ表示されるため、ステップでは製品名は言及されません)。シナリオの最後にこの要件をテストする方法はありません。(まあ、ユーザーが製品をカートに追加した直後にテストで情報を収集し、シナリオの最後に期待されるカウントをアサートすることもできますが、それは無意味に卑劣で混乱を招きます。) 代わりに、自然な位置で正しいカウントをアサートします。ユーザーに表示されるとすぐに、シナリオに配置します。
同様に、Then I should see the account creation form重要Then I should see the checkout form with 1 product, "Elliptical Juicer"な要件をテストするのが自然なシナリオのポイントでテストできます。
プロセス中にユーザーが見るものは気にせず、製品が途中でシナリオの最後に到達するかどうかだけを気にしたとします。Thenその後、中間ステップを省略できます。
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
And I request to check out
And I create an account
And I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
And I create an account意外ですね。チェックアウト中にゲストユーザーがアカウントを作成するように求められていることを読者が推測する必要があります。私が提供したシナリオの最初のバージョンのように、はっきりと言う方が明確です。
上記の懸念事項のどれも納得できず、要件が満たされていることを主張する必要がある全体的なシナリオの各ポイントに対して個別の Gherkin シナリオを作成したとします。
Scenario: Guest adds a product to their shopping cart
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
Then I should see 1 product in my shopping cart
Scenario: Guest with a product in their shopping cart attempts to check out
Given I have a product in my shopping cart
When I request to check out
Then I should see the account creation form
Scenario: Guest creates an account
Given I have a product named "Elliptical Juicer" in my shopping cart
And I am on the account creation form
When I create an account
Then I should see the checkout form with 1 product, "Elliptical Juicer"
Scenario: Newly registered user checks out
Given I am a user
And I have a product named "Elliptical Juicer" in my shopping cart
And I am on the checkout form
When I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
それはひどい！まず、どのシナリオも利害関係者がシナリオとして考えるようなものではありません。Given第 2 に、中間状態の 1 つが変更されると、次のシナリオのために中間状態をアサートするステップと、中間状態を設定するステップの 2 つのステップを変更する必要があります。これらの各Givenステップは、間違った状態を設定する機会、つまり統合エラーを起こす機会です。この一連のシナリオは、単一のシナリオよりも統合テスト スイートとしての価値がはるかに低くなります。一連の単体テストをほとんど書いたことがあるかもしれません。
すべてのシナリオをエンド ツー エンドで作成すると、重複が発生する可能性が高いのは事実です。通常のコードよりも単体テストで重複を許容するように、Gherkin シナリオでは単体テストよりも重複を許容します。わかりやすさに妥協しないでください。シナリオを分割し、重要なポイント (上記の例での製品の作成など) でのみ s を使用Givenし、シナリオの統合テスト機能を弱めていることを認識してください。
また、受け入れテストは自動化されたテスト スイートの一部に過ぎないことにも注意してください。重要なシナリオをカバーするのに十分な受け入れテストのみを作成し、詳細を単体テストでカバーします。多くの場合、受け入れテストの重複に対する解決策は、1 つを単体テストに置き換えることです。