Mescolando Allora e Quando nel BDD Storie utente / prove di collaudo

Question

Come si fa a gestire storie di utenti / test di accettazione che hanno lunghe catene come questo, in cui l'allora / Quando si mescolano insieme? E 'meglio per dividere questo in un test di accettazione separata in cui uno dei test che viene visualizzata la finestra e poi la seconda testa il comportamento dopo è stato dimostrato che la finestra?

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

Il tuo scenario sembra un po 'lungo, ed è piuttosto pesantemente legato alla gui. Che cosa accadrebbe se si legò alle capacità del sistema, invece?

Scenario: I want to remove an item from my cart
  Given I have a cart containing "xyz"
  When I remove "xyz" from my cart
  Then my cart should be empty.

Lo scenario ora descrive roba che è utile per l'utente, ed è più facile refactoring.

I Love BDD tanto quanto me fare perché ho avuto una situazione molto simile a questo. Abbiamo avuto 120 test di accettazione e sono stati in gran parte fallendo. Qualcuno aveva messo una finestra di dialogo di conferma in gran parte simile a quello che lei descrive, e si è rotto subito più di 80 prove di collaudo. Trasformandole in scenari con alto livello, passi riutilizzabili invece, possiamo facilmente refactoring e mantenere le prove operative anche i meccanismi che utilizziamo per implementare le capacità del cambiamento del sistema. Il click effettivo di pulsanti che accade all'interno di tali passi riutilizzabili, ed è bene avere più di un'azione di interfaccia utente per ogni passo.

ho scritto uno scenario qui che fa questo se è utile (si tratta di un DSL, piuttosto che l'inglese, ma si dovrebbe ottenere l'idea):

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

Answer 2

La questione è davvero uno di quello che i "rami" sono.

Se non ci sono più passaggi ci devono essere scelte degli utenti ad ogni passo. Ci dovrebbe essere più "Quando" 's. Questo dovrebbe costituire un albero ricco di un sacco di alternative selezionati dall'utente in ogni ramo. Ogni possibile risultato dovrebbe avere il proprio test per effettuare le varie scelte e arrivare a quel risultato.

Una sequenza tre fasi con due scelte dall'utente è di 8 percorsi possibili. Diversi percorsi possono giungere allo stesso risultato (o non). Ma si dovrebbe avere più percorsi attraverso questo.

Se è solo sequenziale (perché qualcuno sentiva come la scrittura passi sequenziali) e l'utente non ha scelte, quindi non è davvero guidato dalla considerazione del comportamento dell'utente, è vero?

non vedo le scelte. Non ci sono scelte == cattivo odore. Ma facile da test, in quanto c'è solo un risultato con una sequenza di passi in cattività in cui l'utente ha pochi o nessun scelte.

Se si lavora fuori le scelte correttamente, allora ogni passo ha più risultati e ogni passo dovrebbe essere testato in modo indipendente.