シナリオのアウトラインで自分の手順に名前を付けるにはどうすればよいですか
質問
私はこのようなものに見えるいくつかのスペックフローテストを持っています:
Scenario: Person is new and needs an email
Given a person
And the person does not exist in the repository
When I run the new user batch job
Then the person should be sent an email
Scenario: Person is not new and needs an email
Given a person
And the person does exist in the repository
When I run the new user batch job
Then the person should not be sent an email
わずか2つのシナリオの代わりに、10の非常によく似たシナリオがあり、すべて手順のタイプがあるため、「シナリオのアウトライン」を使用したいと思います。残念ながら、私は自分のステップを書き直すための読みやすい方法を思いつくのに本当に苦労しています。
現在、私はこれを思いつきましたが、不格好に見えます:
Scenario: Email batch job is run
Given a person
And the person '<personDoes/NotExist>' exist in the repository
When I run the new user batch job
Then the person '<personShould/NotGetEmail>' be sent an email
Examples:
| !notes | personDoes/NotExist | personShould/NotGetEmail |
| Exists | does not | should |
| No Exist | does | should not |
私もこれを考えました、そしてそれはきれいですが、それはほとんど意味を伝えません
Scenario: Email batch job is run
Given a person
And the person does exist in the repository (is '<personExist>')
When I run the new user batch job
Then the person should be sent an email (is '<sendEmail>')
Examples:
| !notes | personExist | sendEmail |
| Exists | false | true |
| No Exist | does | false |
「しない」、「そうではない」、「そうすべきでない」、「持っていない」、「持っていない」などの概念をパラメーター化するより良い方法を持っている人はいますか?この時点で、私はそれがより読みやすいので、すべてを別のシナリオとして残すことを考えています。
解決
これが私が過去にしたことです:
Given these people exist in the external system
| Id | First Name | Last Name | Email |
| 1 | John | Galt | x |
| 2 | Howard | Roark | y |
And the following people exist in the account repository
| Id | External Id | First Name | Last Name |
| 45 | 1 | John | Galt |
When I run the new user batch job
Then the following people should exist in the account repository
| External Id | First Name | Last Name | Email |
| 1 | John | Galt | x |
| 2 | Howard | Roark | y |
And the following accounts should have been sent an email
| External Id | Email |
| 2 | y |
table.createset()およびtable.createset()helperメソッドをSpecflowで使用して、データベースの偽の外部システムリポジトリとアカウントテーブルのテーブルをすばやくデータに変えることができます。
次に、table.comPareToSet(AccountrePository.getAccounts()を使用して、「then」節のテーブルをデータベースのレコードと比較できます。
きちんとしたことは、あなたが書いたすべての手順は複数の状況で再利用可能であるということです。テーブルのデータを変更するだけで、Specflowがテストを書き込みます。
それが役立つことを願っています!
他のヒント
たぶん、それらを2つのシナリオに分割する必要があります
Scenario Outline: User exists in the repository
Given a person
| Field | Value |
| First | <first> |
| Last | <last> |
And the person exists in the repository
When the user attempts to register
Then the person should be sent an email
Examples:
| first | last |
| Bob | Smith |
| Sarah | Jane |
そして、反対の別のシナリオ。これにより、シナリオが非常に明確になります。一般的な手順が一般的に表現されている場合は、それらを再利用できます。私もユーザーのアプローチから来ようとします