Gli scenari BDD dovrebbero includere dati di test effettivi o semplicemente descriverli?

Question

Siamo arrivati ​​a un punto in cui ci siamo resi conto che ci sono due opzioni per specificare i dati di test quando si definisce un tipico scenario CRUD:

Opzione 1: descrivere i dati da utilizzare, e lasciare che l'attuazione definire il dati

Scenario: Create a region 
    Given I have navigated to the "Create Region" page 
     And I have typed in a valid name 
     And I have typed in a valid code 
    When I click the "Save" button 
    Then I should be on the "Regions" page 
    And the page should show the created region details 

Opzione 2: esplicitamente affermano i dati di test da utilizzare

Scenario: Create a region 
    Given I have navigated to the "Create Region" page 
     And I have filled out the form as follows 
     | Label | Value | 
     | Name | Europe | 
     | Code | EUR | 
    When I click the "Save" button 
    Then I should be on the "Regions" page 
    And the page should show the following fields 
     | Name | Code | 
     | Europe | EUR | 

In termini di bene calze e inconvenienti, quello che abbiamo stabilito è che:

L'opzione 1 copre bene il caso in cui la definizione di dire "nome valido" cambia. Questo potrebbe essere più difficile da gestire se optassimo con l'Opzione 2, in cui i dati del test si trovano in più punti. L'opzione 1 descrive esplicitamente ciò che è importante sui dati per questo test, specialmente se si tratta di uno scenario in cui dicevamo qualcosa come "ha inserito un numero di carta di credito non valido". Inoltre "sente" più astratto e BDD in qualche modo, essendo più interessato alla descrizione che all'implementazione.

Tuttavia, l'opzione 1 utilizza passaggi molto specifici che sarebbero difficili da riutilizzare. Ad esempio "la pagina dovrebbe mostrare i dettagli della regione creata" probabilmente verrà utilizzata solo da questo scenario. Viceversa, potremmo implementare la "pagina dovrebbe mostrare i seguenti campi" dell'opzione 2 in modo che possa essere riutilizzata molte volte da altri scenari.

Penso anche che l'opzione 2 appaia più adatta ai clienti, poiché possono vedere con l'esempio cosa succede invece di dover interpretare termini più astratti come "valido". L'opzione 2 sarebbe più fragile però? Rifattorizzare il modello potrebbe significare rompere questi test, mentre se i dati del test sono definiti in codice, il compilatore ci aiuterà con le modifiche del modello.

Apprezzo che non ci sarà una risposta giusta o sbagliata qui, ma vorrei sentire le opinioni della gente su come deciderebbero quale usare.

Grazie!

Answer 1

Direi che dipende. Ci sono momenti in cui uno scenario potrebbe richiedere una grande quantità di dati per completare una corsa andata a buon fine. Spesso la maggior parte di questi dati non è importante per la cosa che stiamo effettivamente testando e quindi diventa rumore che distrae dalla comprensione che stiamo cercando di ottenere con lo Scenario.Ho iniziato a utilizzare qualcosa che chiamo un pattern Dati predefiniti per fornire dati predefiniti che possono essere uniti a dati specifici per lo scenario. Ho scritto su di esso qui:

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

Spero che questo aiuta.

Answer 2

preferisco l'opzione 2.

Per l'utente business che è immediatamente chiaro che cosa gli ingressi sono e le uscite. Con l'opzione 1 non sappiamo quali siano i dati validi, quindi la tua implementazione potrebbe essere sbagliata.

Si può essere ancora più espressivo con l'aggiunta di dati non validi anche, se del caso

Scenario: Filter for Awesome 
    Given I have navigated to the "Show People" page 
    And I have the following data 
    | Name | Value | 
    | John | Awesome| 
    | Bob | OK  | 
    | Jane | Fail | 
When I click the "Filter" button 
Then the list should display  
    | Name | Value | 
    | John | Awesome | 

Tuttavia, è necessario mantenere i dati per cui il suo descritta in termini di dominio, piuttosto che la specifica implementazione. Questo ti permetterà di testare a diversi livelli nella tua applicazione. per esempio. UI Service ecc.

Answer 3

Ogni volta che penso a questo, cambio idea. Ma se ci pensate - il test è dimostrare che è possibile creare una regione. Un criterio incontrato da entrambe le opzioni. Ma sono d'accordo sul fatto che le indicazioni visive con l'opzione 2 e la compatibilità degli sviluppatori siano probabilmente troppo buone per rifiutare. In esempi come questo, almeno.