Est-il correct d'avoir plusieurs groupes de donnés / quand / alors dans un seul scénario de cornichons
J'écris des tests d'acceptation dans Gherkin où je veux tester plusieurs changements dans l'interface utilisateur d'une application Web en fonction d'une action initiale. Voici un exemple:
Scenario: Cancel editing a new text asset
Given the user "[email protected]" is logged in
When the user navigates to "/build/"
And the user clicks the "Sandbox" link
And the user inputs "Test story for canceling editing of a new text asset" for the "title" field
And the user inputs "Test User" for the "byline" field
And the user inputs "My summary, so exciting!" for the "summary" textarea
And the user clicks on "Untitled Section" in the section list
And the user clicks the "Text" icon in the "center" container
And the user inputs the following text in the rich text editor:
"""
Test text for asset. This is cool.
"""
And the user clicks the "cancel" button
Then the following text is not present:
"""
Test text for asset. This is cool.
"""
And the "Image" icon is present
And the "Text" icon is present
When the user refreshes the browser
And the user clicks on "Untitled Section" in the section list
Then the following text is not present:
"""
Test text for asset. This is cool.
"""
When the user opens the asset drawer
Then the following text is not present:
"""
Test text for asset. This is cool.
"""
Notez qu'il existe plusieurs groupes d'étapes Quand/Alors, pour tester les réponses de l'action initiale. Alors que la plupart des implémentations d'étapes ignorent le mot-clé préfixe, et je suis sûr que je peux exécuter ce test, existe-t-il une meilleure façon de tester les différents résultats? Est-il préférable d'écrire plusieurs scénarios avec la même configuration mais des instructions "Then" différentes?
N'oubliez pas que vous ne devez tester qu'un seul comportement/fonctionnalité à la fois. La règle générale est que vous ne devez utiliser qu’une seule étape When :
Given some state before action
And some other state before action
...
When only one action
Then assert correct output
And assert correct output
...
Vous voyez - une seule ligne de Quand, sans Ands sous Quand. Si vous utilisez plusieurs étapes When à la place, vous créez un script de test, pas une spécification. Vos tests seront difficiles à comprendre et vous remarquerez que vous ajoutez de plus en plus d'étapes lorsque l'implémentation sous-jacente change.
Vous devez également garder la logique sous-jacente cachée, car vous ne voulez pas la changer chaque fois que vous changez quelque chose de non pertinent. Exemple:
Et l'utilisateur entre "Mon résumé, tellement excitant!" pour la zone de texte "résumé"
Que faire si vous changez le champ récapitulatif d'une zone de texte en un type d'entrée? Vous devez changer le scénario (cauchemar de maintenance) ou vous laisser mentir (pire que de ne pas avoir de scénario). Vous devriez plutôt écrire:
When the user describes it as "so exciting!"
Mais encore, la structure de l'ensemble du scénario est mauvaise. Posez-vous la question: ce que je veux vérifier? Si j'étais une personne qui veut comprendre la logique métier de la fonctionnalité, j'aimerais voir quelque chose comme:
Scenario: Cancel editing a new text asset
Given I edit the Sandbox details with some data
When I cancel editing
Then Sandox details should be empty
C'est tout!
Comment y parvenir? Déplacez toute la logique non pertinente plus en profondeur, utilisez le modèle PageObject etc. Et lisez à propos de spécification par exemple