BDD - TDD in un modo BDD
In TDD, il termine "Test di accettazione" è fuorviante. I test di accettazione rappresentano effettivamente il comportamento previsto del sistema. Nelle pratiche Agile, viene enfatizzata la collaborazione dell'intero team e le interazioni con il cliente e gli altri stakeholder. Ciò ha determinato la necessità di utilizzare termini facilmente comprensibili da tutte le persone coinvolte nel progetto.
TDD ti fa pensare al necessario Behavior e quindi il termine "comportamento" è più utile del termine ‘Test’. BDD è Test Driven Development con un vocabolario che si concentra sul comportamento e non sui test.
Nelle parole di Dan North, "Ho trovato il passaggio dal pensiero nei test al pensiero nel comportamento così profondo che ho iniziato a fare riferimento a TDD come BDD, o Behaviour Driven Development". TDD si concentra su come funzionerà qualcosa, BDD si concentra sul motivo per cui lo costruiamo.
BDD risponde alle seguenti domande spesso affrontate dagli sviluppatori:
| Domanda | Risposta |
|---|---|
| Dove iniziare? | fuori dentro |
| Cosa provare? | Storie degli utenti |
| Cosa non testare? | qualunque altra cosa |
Queste risposte danno luogo alla struttura della storia come segue:
Story Framework
Come un [Role]
Voglio [Feature]
così che [Benefit]
Ciò significa: "Quando a Feature viene eseguito, il risultato Benefit sta alla persona che suona il file Role.'
BDD risponde inoltre alle seguenti domande:
| Domanda | Risposta |
|---|---|
| Quanto testare in una volta? | molto poco concentrato |
| Come chiamare i loro test? | modello di frase |
| Come capire perché un test fallisce | documentazione |
Queste risposte danno come risultato il framework di esempio:
Example Framework
Given qualche contesto iniziale,
When si verifica un evento,
Then garantire alcuni risultati.
Ciò significa: "A partire dal contesto iniziale, quando si verifica un particolare evento, sappiamo quali sono i risultati should be. "
Pertanto, l'esempio mostra il comportamento previsto del sistema. Gli esempi vengono utilizzati per illustrare diversi scenari del sistema.
Storia e scenari
Consideriamo la seguente illustrazione di Dan North su un sistema ATM.
Storia
As a cliente,
I want prelevare contanti da un bancomat,
so that Non devo fare la fila in banca.
Scenari
Ci sono due possibili scenari per questa storia.
Scenario 1 - L'account è in credito
Given l'account è in credito
And la carta è valida
And il distributore contiene contanti
When il cliente richiede contanti
Then assicurarsi che l'account venga addebitato
And assicurarsi che il contante venga erogato
And assicurarsi che la carta venga restituita
Scenario 2 - Il conto è scoperto oltre il limite di scoperto
Given il conto è scoperto
And la carta è valida
When il cliente richiede contanti
Then assicurarsi che venga visualizzato un messaggio di rifiuto
And assicurarsi che non vengano erogati contanti
And assicurarsi che la carta venga restituita
L'evento è lo stesso in entrambi gli scenari, ma il contesto è diverso. Quindi, i risultati sono diversi.
Ciclo di sviluppo
Il ciclo di sviluppo per BDD è un outside-in approccio.
Step 1- Scrivi un esempio di valore aziendale di alto livello (esterno) (utilizzando Cucumber o RSpec / Capybara) che diventi rosso. (RSpec produce un framework BDD nel linguaggio Ruby)
Step 2 - Scrivi un esempio RSpec di livello inferiore (interno) per il primo passaggio dell'implementazione che diventa rosso.
Step 3 - Implementa il codice minimo per superare l'esempio di livello inferiore, vederlo diventare verde.
Step 4 - Scrivi il successivo esempio RSpec di livello inferiore spingendo verso il passaggio 1 che diventa rosso.
Step 5 - Ripeti i passaggi Passaggio 3 e Passaggio 4 fino a quando l'esempio di alto livello nel Passaggio 1 diventa verde.
Note - I seguenti punti dovrebbero essere tenuti a mente:
Red/green lo stato è uno stato di autorizzazione.
Quando i tuoi test di basso livello sono verdi, hai il permesso di scrivere nuovi esempi o refactoring dell'implementazione esistente. Non devi, nel contesto del refactoring, aggiungere nuove funzionalità / flessibilità.
Quando i tuoi test di basso livello sono rossi, hai il permesso di scrivere o modificare il codice di implementazione solo per rendere verdi i test esistenti. Devi resistere all'impulso di scrivere il codice per superare il tuo prossimo test, che non esiste, o implementare funzionalità che potresti pensare siano buone (il cliente non l'avrebbe chiesto).