Gherkin: riutilizza semplicemente le affermazioni date come affermazioni Quando... accettabili?

Question

Ecco tre esempi di istruzioni BDD che dovrebbero aiutare a spiegare la mia domanda:

Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page

Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

contro

Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

Quindi lo scenario 1 sopra va bene, ma quale è il migliore tra le affermazioni 2 e 3.L'affermazione 2 si legge bene e in modo più conciso.Ma la definizione del mio passo per "dato ho effettuato l'accesso al sistema usando il nome utente" miusername "e" mypassword "" dovrà ripetere le chiamate agli oggetti della pagina (o equivalente) quello scenario chiamato ...sembra uno sforzo maggiore da parte degli sviluppatori.

Quindi mi chiedevo davvero se qualcuno sa quale sia la migliore pratica.Ho cercato in rete e ho trovato il seguente documento:http://docs.behat.org/guides/1.gherkin.html

Questo suggerimento dello scenario 2 è il migliore, ma poi scrive:"Autentica un utente (un'eccezione alla raccomandazione di non interazione.Le cose che "sono accadute prima" vanno bene)", il che si presta in qualche modo allo scenario 3.

Saluti,

Charlie

Answer 1

Ecco la mia recensione degli scenari che hai scritto.

Scenario 1

Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page

.

Pro : Usando correttamente le dichiarazioni fornite, quando e quindi. In questo scenario, il dato imposta lo stato iniziale del sistema, quando indica le azioni che un utente prenderà e quindi i dettagli delle asserzioni effettuate per verificare il comportamento del sistema.

Contro : Mentre ciò che hai scritto funzionerà, il problema che hai è che questo test è fragile. Se la tua azienda dovesse richiedere che anche un token di sicurezza dipendente dal tempo debba essere specificato durante il log-in (ad esempio), è necessario aggiungere un altro passo per inserire questo campo aggiuntivo. Tuttavia, se hai riscritto questo passo per essere dichiarativo E.G.

Given I am on the login screen
When I submit valid log-in criteria
Then I should see the login successful page

.

Quindi se il processo di accesso è stato modificato, è necessario modificare solo il codice, lo scenario rimarrebbe lo stesso.

Scenario 2

Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

.

Pro : come sopra.

Contro : Ancora una volta il test è fragile come è imperativo I.e. Stai specificando le credenziali di accesso esatte e un prodotto specifico. Sarei riconosciuto questo come:

Given I am logged into the system
When I purchase a product
Then I should have that product in the product inventory

.

È possibile salvare il prodotto specificato nel "passaggio" in scenariocontext.current < / a>. Saresti quindi in grado di riutilizzare questo valore nella tua "Poi" per affermare che è presente nell'inventario del prodotto.

Scenario 3

Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

.

Contro : Questo è il peggiore dei tuoi scenari in modo errato utilizzando la dichiarazione data. Una data affermazione dovrebbe essere utilizzata per definire uno stato di sistema iniziale per il test, quindi in questo caso "Dato che sono sulla schermata di accesso" è un uso corretto, ma "dato I inserire il nome utente valido" MyUserName "" è un uso errato . Non è corretto come indicare un'azione utente, quindi dovrebbe essere coperta da un quando. Sì, è possibile utilizzare un dato per eseguire gli stessi passaggi programmatici come quando, ma non lo fa bene!

Cambiare questo scenario sulla versione che ho suggerito nello scenario 2.

Answer 2

In primo luogo, non c'è assolutamente nulla in Gherkin che ti impedisca di scrivere le specifiche in qualsiasi ordine, puoi persino produrre specifiche composte come

Given ...
When... 
Then ...
When ...
Then ...
Given ...
When ... 
Then ...

Allora perché vorresti farlo?

Bene, per prima cosa consideriamo una quarta variante del tuo scenario

Scenario: User logs in and buys a product
  Given I am on the login screen
  When I enter the valid username "myUsername"
  And I enter the valid password "myPassword"
  And I press the login button
  Then I should see the login successful page
  When I purchase the product "myProduct"
  Then I should have "myProduct" in the product inventory

Questo ovviamente è solo un composto di 1 e 2.Potresti aver scritto questo perché avevi finito di testare l'accesso e volevi scrivere e testare rapidamente l'acquisto di un prodotto.Hai già il codice per Bindings nello scenario uno e ora dobbiamo semplicemente scrivere i collegamenti per lo scenario due.Potresti considerare questo il tuo cambiamento pragmatico più semplice e lo rifattorificherai in seguito.Non c'è niente di sbagliato in questo, eseguire i test potrebbe essere più veloce, ma non è esattamente l'ideale.

Ora immagina che, a causa della natura del tuo negozio, tu abbia scritto molti test che mettono alla prova diversi processi di acquisto.Potremmo testare cosa succede quando aggiungi nuovamente lo stesso articolo al carrello, o se provi ad acquistare qualcosa esaurito, o esperienze di pagamento diverse se desideri una consegna speciale.In effetti, il tuo negozio ha così tanto successo che devi essere davvero sicuro sul web e modificare la procedura di accesso.Sfortunatamente ora hai quelle tre righe

Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"

ripetuto in tutti i tuoi scenari.Se accidentalmente interrompiamo il nostro processo di accesso con un codice errato, improvvisamente tutti i nostri test falliscono.Ti viene presentato un muro rosso e non puoi davvero restringere il campo da cui iniziare a guardare i problemi.Poiché dipendiamo dall'accesso prima di eseguire il nostro scenario, non possiamo isolare l'accesso dall'acquisto.

Questa è davvero la differenza tra a Given e un When.UN When è lì per indicare che stiamo eseguendo un processo, a Given è un mezzo per influenzare direttamente l'ambiente di runtime in modo da avere semplicemente lo stato corretto.Fondamentalmente è la differenza tra

//Given
isLoggedIn = true

//When
if CheckValidPasswordForUser(user, password)
   isLoggedIn = true

IL Given non ha modo di fallire.

Quindi, tornando alla tua domanda iniziale,

Puoi riutilizzare Givenè come WhenS? Sì, ma a lungo termine ti confonderà.

Ma se lo chiedi Puoi riutilizzare Whenè come GivenS? allora ti consiglierei sicuramente di non farlo.Ciò nasconderà il fatto che si sta testando qualcosa che potrebbe rompersi.

Infine c'è un'altra cosa da considerare e questo è il dominio delle tue specifiche.Dan North ha un ottimo articolo su questo Comunque di chi è il dominio?, ma l'essenza generale applicata al tuo esempio qui è che quando guardi l'acquisto di un prodotto puoi semplicemente scrivere

Given I am logged in as a customer

O

Given I am logged in as an administrator

perché le parti del nome utente e della password riguardano l'accesso e non i prodotti, e in questo modo sei protetto dalla riscrittura di tutti i tuoi scenari quando modifichi il processo di accesso per utilizzare qualcos'altro.