ガーキンで「GivenWhenThen WhenThen」テストを書くことは許容されますか？
ガーキンで「GivenWhenThen WhenThen」テストを書くことは許容されますか？実際の例は次のとおりですすべてのAllPlayers.com
Scenario: Successfully register a user
Given I am on homepage
And I am not logged into an account
When I follow "create a new account"
And I fill in "First Name" with "Bobby"
And I fill in "Last Name" with "Bricks"
And I fill in "E-mail" with "[email protected]"
And I select "Jun" from "Birthday Month"
And I select "22" from "Birthday Day"
And I select "1985" form "Birthday Year"
And I select "Male" from "Gender"
And I fill in "Password" with "123testing"
And I fill in "Confirm Password" with "123testing"
And I solve the captcha math problem
And I click "Create new account"
Then I should see "the user dashboard"
And I should see the Registration Wizard
When I Push "Proceed to next step"
Then the "First Name" field should contain "Bobby"
And the "Last Name" field should contain "Bricks".
Behatを使用して機能することはわかっているので、構文解析は問題ありません。より良いテストを書こうとしているだけです。私は最初に書くことができ、それからAnd the Registration Wizard should be filled out with dataしかし、それは十分に具体的ではないようです...
提案？
書かれている機能の対象読者によって異なります。あなたがそこに持っているガーキンは、利害関係者（つまり、技術者ではないが、ビジネスとウェブサイトに既得権を持っている人）と一緒に書かれていない可能性が高いようです。 BDDは本当に会話要件と期待についてです-そしてGherkinは誰もが標準的/認識された方法を提供するツールです要件と期待を書くことができることを読むことができるはずです。開発者向けの自動テストおよびおそらくテスター向けのテストスクリプトとして機能する方法で。
今すぐ開発者の帽子を脱がせようとしています-ビジネスの利害関係者はむしろ読み、簡単に理解したいと思います...
Scenario: Should be able to successfully register on website
Given I am new to the website
And I want to register for a user account
When I go to the registration form
And I complete all the required registration details correctly
Then I will be registered on the website
And I will be automatically logged in
この仕様の舞台裏で同じテストを作成することはできますが、この仕様の読者数は多いため、誰もが理解する必要のある、より理解しやすい要件です。私はあなたが持っているものに価値がないと言っているのではありません-それから遠く離れています。非常に有効なテストになります。ただし、これは開発者固有のものであり、UI実装と高度に結合しています（UIをリファクタリング/再設計する場合は、要件をリファクタリングする必要があります...）。
私はあなたのようなガーキンの仕様をたくさん持っていることから始めました-そして私は今でも時々それらを使用しています。テストフレームワークが構築されたら、小さなガーキンは、データ駆動型/構成可能な単体テストを作成するための非常に優れた方法です。そして、それらはまだ私の開発プロセスに大きな価値を持っています。しかし、私はより「純粋な」仕様を「開発者」の仕様から分離しようとしていますが、フォルダーとタグ/カテゴリーです。
編集：要約すると、私が得ているのは...あなたが持っているものは素晴らしい「テスト」ですが、かなり悪い「要件」だと思います。しかし、それに固執してください！
はい、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"それはひどい！まず、どのシナリオも、利害関係者がシナリオとして考えるものではありません。次に、中間状態の1つが変更されると、2つのステップを変更する必要があります。中間状態をアサートするステップと、次のシナリオの中間状態を設定する
Givenステップです。これらのGivenステップのそれぞれは、間違った状態を設定する機会です。つまり、統合エラーを起こします。この一連のシナリオは、単一のシナリオよりも統合テストスイートとしての価値がはるかに低くなります。あなたはほとんど一連のユニットテストを書いたかもしれません。
すべてのシナリオをエンドツーエンドで作成すると、重複が発生する可能性が高いのは事実です。通常のコードよりも単体テストで重複を許容するのと同じように、Gherkinシナリオでは単体テストよりもさらに重複を許容します。理解しやすさを妥協しないでください。シナリオを分割し、重要なポイント（上記の例の製品の作成など）でのみGivensを使用し、シナリオの統合テスト能力を薄めていることを認識してください。
また、受け入れテストは自動テストスイートの一部にすぎないことに注意してください。重要なシナリオをカバーするのに十分な受け入れテストのみを記述し、ユニットテストで詳細をカバーします。多くの場合、受け入れテスト間の重複に対する解決策は、1つを単体テストに置き換えることです。
私もノーと言います。
私の別の投稿で、ダニエルFはこの素晴らしい記事を見つけました。関連するセクションは次のとおりです。
Give-When-Thenステップは順番に表示される必要があり、繰り返すことはできません。ギブンはWhenまたはThenに従わない場合があり、WhenはThenに従わない場合があります。理由は単純です。単一のWhen-Thenペアは、個々の動作を示します。これにより、上記のテストで、（1）検索バーからの検索と（2）画像検索の実行という2つの動作が実際にどのようにカバーされているかを簡単に確認できます。ガーキンでは、1つのシナリオが1つの動作をカバーします。したがって、1つではなく2つのシナリオが必要です。複数のWhen-Thenペアを作成する場合は、代わりに個別のシナリオを作成してください。 （注：一部のBDDフレームワークでは、無秩序な手順が許可される場合がありますが、それでも反動作になります。）
https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/
私はノーと言うでしょう。
テストが失敗すると、システムのどこで失敗が発生したかがわかります。あなたの例のような長いテストはもろくなりがちで、より高いレベルのメンテナンスが必要です。
あなたはあなたのテストが何をテストしているのかを定義する必要があります（それは一つのことであるはずです）あなたのテストを読んで
- それはフォーム検証テストである可能性があります。
- それは登録テストかもしれません。
- ユーザーダッシュボードのテストである可能性があります。
障害がどこにあり、それがコードのどこに関連しているかを調査するには、かなりの時間がかかります。
私もノーと言います。
ギブンはセットアップの前提条件です。 Whenはアクションです（何もしない場合があります）Thenフォームがアサートします。
さらにアクションが必要な場合は、テストを分解してください。
これは、最初のThenが問題のローカライズに失敗すると、はるかに便利になります。