Mixage à ce moment-là et dans les BDD Histoires d'utilisateur/Tests d'acceptation

Question

Comment gérez-vous les user stories/tests d'acceptation qui ont de longues chaînes comme celle-ci, où se mêlent alors Then/When? Est-il préférable de diviser ceci en un test d'acceptation séparé où l'on teste que la boîte de dialogue apparaît et ensuite la seconde teste le comportement après que la boîte de dialogue a été montrée?

Feature: Confirmation before removing products from cart 
    In order to avoid accidentally removing an item from my cart 
    As a Customer 
    I want a confirmation dialog to ask me if I'm sure I want to remove an item 

    Scenario: I want to remove an item from my cart 
    Given I have added item "xyz" to my cart 
    When I click "Remove" 
    Then a confirmation dialog pops up 
    And it asks "Are you sure you want to remove this from your cart" 
    When I click "Yes" 
    Then item "xyz" should be removed from my cart 

Answer 1

Votre scénario semble un peu long, et il est assez fortement lié à l'interface graphique. Que se passerait-il si vous le liiez aux capacités du système à la place? Le scénario décrit maintenant des éléments utiles à l'utilisateur, et il est plus facile de les refactoriser.

J'adore BDD autant que moi parce que j'ai eu une situation comme celle-ci. Nous avons eu 120 tests d'acceptation et ils échouaient pour la plupart. Quelqu'un avait placé une boîte de dialogue de confirmation semblable à celle que vous décrivez, et il a instantanément dépassé les 80 tests d'acceptation. En les transformant en scénarios avec des étapes réutilisables de haut niveau, nous pouvons facilement refactoriser et maintenir le fonctionnement des tests même si les mécanismes que nous utilisons pour implémenter les capacités du système changent. Le clic réel des boutons se produit dans ces étapes réutilisables, et il est possible d'avoir plus d'une action d'interface utilisateur par étape.

j'ai écrit un scénario ici qui fait cela si elle est utile (c'est un DSL plutôt que l'anglais mais vous devriez avoir l'idée):

http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs

Answer 2

La question est vraiment celle de ce que sont les "branches".

S'il y a plusieurs étapes, il doit y avoir des choix de l'utilisateur à chaque étape. Il devrait y avoir plusieurs "Quand". Cela devrait former un arbre riche avec beaucoup d'alternatives choisies par l'utilisateur dans chaque branche. Chaque résultat possible devrait avoir son propre test pour faire les différents choix et arriver à ce résultat.

Une séquence en trois étapes avec deux choix utilisateur est de 8 chemins possibles. Des chemins différents peuvent aboutir au même résultat (ou non). Mais vous devriez avoir plusieurs chemins à travers cela.

Si c'est juste séquentiel (parce que quelqu'un a eu l'impression d'écrire des étapes séquentielles) et que l'utilisateur n'a pas le choix, alors ce n'est pas vraiment dû au comportement de l'utilisateur, n'est-ce pas?

Je ne vois pas les choix. Pas de choix == mauvaise odeur. Mais facile à tester puisqu'il n'y a qu'un seul résultat avec une séquence d'étapes captives où l'utilisateur a peu ou pas de choix.

Si vous définissez correctement les choix, chaque étape a plusieurs résultats et chaque étape doit être testée indépendamment.