BDDのGherkin形式で受け入れ基準を定義するときに好ましいアプローチはありますか？
次のようにシナリオを分割する必要があります...
Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email | phone |
| [email protected] | 012345678 |
And I save the details
Then the details are correctly saved
Scenario: User saves contact details with a very long email address
Given I am on the contact details page
When I enter the following details
| email | phone |
| [email protected] | 012345678 |
And I save the details
Then the details are correctly saved
Scenario: User saves contact details with a very long phone number
etc
または、複数のアウトラインを持つ単一のシナリオを使用する必要がありますか？
Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email | phone |
| <email> | <phone> |
And I save the details
Then the details are correctly saved
Examples:
| email | phone |
| [email protected] | 012345678 |
| [email protected] | 012345678 |
| [email protected] | 012345678901234567890 |
後者は適応/追加が簡単かもしれませんが、私にはシナリオの基本的な概念が失われます。
更新私はちょうどこの正確なポイントを議論する次の記事に出くわしました。後者を提案することはより良いアプローチです。https://www.hindsightsoftware.com/blog/scenario-outlines
次のようなことを示唆しています。
Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email | phone |
| <email> | <phone> |
And I save the details
Then the details are correctly saved
Examples:
| scenario | email | phone |
| basic details saved | [email protected] | 012345678 |
| very long email address | [email protected] | 012345678 |
| very long phone number | [email protected] | 012345678901234567890 |
一般的な慣例として、入力を変更しても同じ出力を期待する場合は、シナリオの概要に適しています。
Thenステップをパラメーター化することはできますが、テストのアサーションを変更すると、テストが根本的に変更されたことを意味するため、これはお勧めしません。これは哲学的でコードのメンテナンスの問題です。
電話番号の最大長を考えてみましょう。例では11文字です。11文字が最大で、その境界の両側をテストするシナリオの概要がある場合、シナリオには失敗する理由が複数あります。まず、11が最大長ではなくなった場合、さらに12が最大長になった場合、そのテストも失敗します。
失敗する複数の理由があるテストは「不安定」です
以下のシナリオの概要は、アサーションと入力を変化させます。つまり、このテストが失敗する理由は複数あります。
Scenario Outline: User saves contact details
Given I am on the contact details page
When I enter the following details
| email | phone |
| [email protected] | <Phone> |
And I save the details
Then the details <Assertion> correctly saved
Examples:
| Phone | Assertion |
| 012345678901234567890 | Are |
| 0123456789012345678901 | Are Not |
電子メールのシナリオを電話番号のシナリオから分離することもお勧めします。
すべてのテストには、失敗する理由が1つだけあるはずです。
以下の2つのシナリオは互いに重複しているように見えますが、入力の大部分の一貫性を保ち、入力の1つを変更するだけで、明らかな理由で失敗するより安定したテストが得られます。
Scenario Outline: User saves contact phone number
Given I am on the contact details page
When I enter the following details
| email | phone |
| [email protected] | <Phone> |
And I save the details
Then the details are correctly saved
Examples:
| Phone |
| 012345678 |
| 012345678901234567890 |
Scenario Outline: User saves contact e-mail address
Given I am on the contact details page
When I enter the following details
| email | phone |
| <Email> | 012345678 |
And I save the details
Then the details are correctly saved
Examples:
| Email |
| [email protected] |
| [email protected] |
これで、シナリオが失敗したときに、シナリオ名から、アプリケーションのどの部分が原因であるかについてのヒントが得られ、デバッグに役立ちます。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加