Le migliori pratiche BDD per la progettazione di scenari Cucumber per i moduli

Question

Diciamo che avete un modulo che crea un nuovo utente. Come scrivi lo scenario di Cucumber?

1.)

Given I am logged in as admin 
When I create a new user 
Then I should see "Successfully created user" 

2.)

Given I am logged in as admin 
When I go to Create new user 
And I fill in "Name" with "Name111" 
And I fill in "Password" with "Password111" 
And I press "Create new user" 
Then I should see "Successfully created user" 

Se si sceglie 1.) dove si documentare i requisiti per un utente (un utente dovrebbe avere un nome e una password) . Vedo che il BDD riguarda il comportamento, ma a un certo punto tu e lo stakeholder devi specificare quali proprietà deve avere un utente, vero?

Sono molto nuovo per BDD quindi apprezzo qualche consiglio ...

Answer 1

È necessario leggere Imperative vs Declarative Scenarios.

--Aslak. Creatore di cetriolo.

Answer 2

O si lavorerà. Con # 1 si crea un passaggio per eseguire il riempimento del modulo. Io preferisco un ibrido di # 1 e # 2, perché io uso Scenario delinea un sacco per esempio:

Background: 
Given the following users exist: 
    | email    | password  | 
    | test@example.com | testpassword23 | 
    | test2@example.com | notthistime  | 
    | test3@example.com | welcomeback  | 

    @login @authentication 
    Scenario Outline: Authentication 
    Given I am on the new user session page 
    When I login with "<s_email>" and "<s_password>" 
    And I press "Login" 
    Then I should see "<s_message>" 

    Examples: 
    | s_email   | s_password  | s_message      | 
    | test@example.com | testpassword23 | Signed in successfully   | 
    | test2@example.com | itriedreallyhard | Invalid email or password.  | 
    | teOst@example.com | testpassword23 | Invalid email or password.  | 

Answer 3

Gli scenari che hai scritto sono abbastanza basso livello. A meno che tu non stia producendo funzionalità di accesso sicuro per la vendita, resterei fedele al caso felice e al test dell'unità/manuale per il resto. Se non lo fai, creerai così tanti scenari che sarà un incubo di manutenzione.

Scopri cosa differenzia il prodotto che stai creando da tutti i prodotti simili, quindi scegli come valore dello scenario. Poi sarà simile a questa:

Given Fred is logged in 
When Fred <does something> 
Then Fred should <get some really differentiating value> 
And <something else happens> 

Stick alle capacità davvero di alto livello, piuttosto che passi basate su form di basso livello. Per esempio:

Given there is already a question on BDD and Cucumber 
Given Peyote is logged in 
When Peyote proposes a question on BDD and Cucumber 
Then Peyote should see other questions on BDD and Cucumber. 

C'è un concetto chiamato "Pagina Paradigma", in cui si crea una classe con tutti i passaggi di basso livello che la pagina o lo schermo possono eseguire. È quindi possibile chiamare i passaggi a basso livello nella pagina all'interno delle fixture di livello Cucumber di livello superiore.

La tua attività sarà molto più impegnata con scenari come questo. Lo scopo principale di BDD non è quello di produrre test automatici, ma di avere conversazioni intorno agli scenari in modo da poter scoprire dove stai andando male e quali altre opzioni potresti prendere in considerazione prima di affrontare il problema di implementare il codice. I test automatici sono un buon sottoprodotto.

Le conversazioni e l'apprendimento che si ottiene discutendo con loro sono le cose che rendono BDD diverso da ATDD (Acceptance Test Driven Development). Ecco perché utilizziamo un linguaggio come Esempio, Scenario, Dato, Quando, Poi, Contesto, Evento, Risultato invece di Test, SetUp, TearDown, Act, Disponi, Asserisci - quindi possiamo parlarne con business, BA e tester nella stessa lingua

Vedere Dan North's article on Deliberate Discovery e il resto del suo blog per altro, e buona fortuna con il BDD!