Comment dois-je nommer mes pas dans un schéma de scénario

Question

J'ai une poignée de tests specflow qui ressemble à quelque chose comme ceci:

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

Sauf qu'au lieu de seulement deux scénarios, j'ai 10 scénarios très similaires, tous avec le type d'étapes, donc je veux utiliser un « Schéma de scénario ». Malheureusement, je vais avoir une période très difficile à venir avec une manière lisible pour réécrire mes pas.

À l'heure actuelle, je suis venu avec cela, mais les regards maladroits:

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               |

J'ai aussi considéré cela, et alors qu'il est plus propre, il ne donne pas un sens presque aussi bien

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     |

Quelqu'un at-il une meilleure façon de concepts comme paramétrage « ne », « ne fonctionne pas », « devrait », « ne devrait pas », « a », « n'a pas »? À ce stade, je pense à quitter le tout comme un scénario différent parce qu'il est plus facile à lire.

Answer 1

Voici ce que je l'ai fait dans le passé:

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     |

Vous pouvez utiliser les méthodes d'aide table.CreateSet () et table.CreateSet () à SpecFlow pour transformer rapidement les tables en données pour votre référentiel de système externe de faux et votre table de compte dans la base de données.

Ensuite, vous pouvez utiliser table.CompareToSet (accountRepository.GetAccounts () pour comparer la table dans votre « Ensuite » clause des enregistrements dans la base de données.

La chose intéressante est, toutes les étapes que vous écriviez sont réutilisables pour plusieurs situations. Tout ce que vous faites est de changer les données dans les tableaux et les essais SpecFlow écrit pour vous.

L'espoir qui aide!

Answer 2

Peut-être que vous devriez les diviser en deux scénarios

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   |

Et puis un autre scénario pour le contraire. Cela permet de maintenir le scénario qui signifie très clairement. Si vos étapes communes sont formulées genericly vous pouvez les réutiliser. J'essaie aussi de venir de l'approche de l'utilisateur