scenari dovrebbero BDD includono i dati di test vero e proprio, o semplicemente lo descrivono?

Question

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

Opzione 1: Descrivere i dati da utilizzare, e lasciare che l'attuazione definire i 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: in modo esplicito comunicare i dati di test per l'uso

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 vantaggi e svantaggi, che abbiamo stabilito è che:

L'opzione 1 ben copre il caso in cui la definizione di dire una cambiamenti "nome valido". Questo potrebbe essere più difficile da affrontare se siamo andati con l'opzione 2 in cui i dati del test è in più punti. Opzione 1 descrive in modo esplicito ciò che è importante circa i dati relativi a questo test, soprattutto se si trattasse di uno scenario in cui si diceva qualcosa del tipo "ha digitato in un numero di carta di credito non valida". E 'anche "sente" più astratto e BDD in qualche modo, di essere più interessato con la descrizione di implementazione.

Tuttavia, Opzione 1 usi passaggi molto specifici che sarebbero difficili da riutilizzo. Per esempio "la pagina deve mostrare i dettagli regione creata" sarà probabilmente sempre e solo essere utilizzati da questo scenario. Al contrario potremmo implementare Opzione 2 di "pagina dovrebbe mostrare i seguenti campi" in un modo che potrebbe essere riutilizzato molte volte da altri scenari.

penso anche l'opzione 2 sembra più client-friendly, come si può vedere con l'esempio quello che sta succedendo, piuttosto che dover interpretare i termini più astratti come "valido". Sarebbe Opzione 2 essere più fragile però? Refactoring del modello potrebbe significare rompere questi test, mentre se i dati del test è definita nel codice il compilatore ci aiuterà con le modifiche del modello.

Mi rendo conto che non ci sarà una risposta giusta o sbagliata qui, ma piacerebbe sentire le opinioni della gente su come si sarebbero decidere quale utilizzare.

Grazie!

Answer 1

direi che dipende. Ci sono momenti in cui uno scenario potrebbe richiedere una grande quantità di dati per completare un percorso di successo. Spesso la maggior parte di tali dati non è importante per la cosa in realtà stiamo testando e quindi diventa rumore distrae dalla comprensione che stiamo cercando di realizzare con lo scenario. Ho iniziato a usare qualcosa che io chiamo uno schema predefinito di dati per fornire dati predefiniti che possono essere uniti con dati specifici per lo scenario. Ho scritto su di esso qui:

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

Spero che questo aiuta.

Answer 2

Io preferisco l'opzione 2.

Per l'utente aziendale è immediatamente chiaro quali gli ingressi sono e le uscite. Con l'opzione 1 non sappiamo quali dati valido è, quindi l'implementazione potrebbe essere sbagliato.

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 |

Si dovrebbe tuttavia mantenere i dati per cui il suo descritta in termini di dominio, piuttosto che l'applicazione specifica. Questo vi permetterà di testare a diversi livelli nella vostra applicazione. per esempio. UI di servizi, ecc ..

Answer 3

Ogni volta che penso a questo cambio idea. Ma se ci pensate - il test è quello di dimostrare che è possibile creare una regione. A Criteri soddisfatti da entrambe le opzioni. Ma sono d'accordo che i segnali visivi con l'opzione 2 e la cordialità degli sviluppatori sono probabilmente troppo bello per rifiutare. In esempi come questo, almeno.