BDD è l'acronimo di Behaviour Driven Development. É un'estensione di Test-driven development (TDD) dove invece di scrivere i casi di test, iniziamo scrivendo un comportamento. Successivamente, sviluppiamo il codice necessario affinché la nostra applicazione esegua il comportamento desiderato.
Lo scenario definito nell'approccio BDD facilita la collaborazione tra sviluppatori, tester e utenti aziendali.
BDD è considerata una best practice quando si tratta di test automatizzati in quanto si concentra sul comportamento dell'applicazione e non sul pensare all'implementazione del codice.
Il comportamento dell'applicazione è al centro dell'attenzione in BDD e costringe gli sviluppatori e i tester a mettersi nei panni dell'utilizzatore.
Il processo nella metodologia BDD consiste in 6 passaggi ed è molto simile a quello di TDD.
1) Scrivi il comportamento dell'applicazione: il comportamento di un'applicazione deve essere scritto in lunguaggio semplice come il linguaggio dal proprietario del prodotto o dagli analisti aziendali o dai QA.
2) Scrivi gli script automatizzati: questo semplice viene quindi convertito in test di programmazione.
3) Implementa il codice funzionale: viene quindi implementato il codice funzionale alla base del comportamento.
4) Verifica se il comportamento ha esito positivo: esegui il comportamento descritto e verifica se ha esito positivo. In caso di successo, passa al comportamento successivo, altrimenti correggi gli errori nel codice funzionale per ottenere il comportamento atteso dell'applicazione.
5) Effettua il refactoring oppure ottimizza il codice: refactoring/ottimizzazione del codice per renderlo più leggibile e riutilizzabile.
6) Ripeti i passaggi 1-5 per il nuovo comportamento: ripeti i passaggi per implementare più comportamenti nella tua applicazione.
Durante il test del software, lo sviluppo guidato dal comportamento si occupa della domanda "Come?". I tester desiderano sapere come testare correttamente il comportamento del codice e non la sua implementazione. Al contrario, nel caso di un test modulare, l'obiettivo è determinare se una singola unità di codice è implementata correttamente. Questa procedura di test si occupa quindi del "Cosa?" ed è un modo veloce per trovare i singoli bug. La domanda "Quando?" si risponde con lo sviluppo guidato dai test che riguarda il processo di esecuzione dei test. Questo processo può includere anche test di modulo o altri metodi di test.
| TDD | BDD |
|---|---|
| Il processo inizia scrivendo un test case. | Il processo inizia scrivendo uno scenario secondo il comportamento previsto. |
| TDD si concentra su come viene implementata la funzionalità. | BDD si concentra sul comportamento di un'applicazione per l'utente finale. |
| I casi di test sono scritti in un linguaggio di programmazione. | Gli scenari sono più leggibili rispetto a TDD poiché sono scritti in un semplice linguaggio (inglese, italiano, ecc..). |
| I cambiamenti delle funzioni dell'applicazione influiscono molto sui casi di test in TDD. | Gli scenari BDD non sono molto influenzati dalle modifiche alle funzionalità. |
| La collaborazione è richiesta solo tra gli sviluppatori. |
È necessaria la collaborazione tra tutte le parti interessate. |
| Potrebbe essere un approccio migliore per i progetti che coinvolgono API e strumenti di terze parti. | Potrebbe essere un approccio migliore per i progetti guidati dalle azioni degli utenti. Ad esempio: sito Web di e-commerce, sistema applicativo, ecc. |
| Alcuni degli strumenti che supportano TDD sono: JUnit, TestNG, NUnit, ecc. | Alcuni degli strumenti che supportano BDD sono SpecFlow, Cucumber, MSpec, ecc. |
| I test in TDD possono essere compresi solo da persone con conoscenze di programmazione. | I test in BDD possono essere compresi da qualsiasi persona, compresi quelli senza alcuna conoscenza di programmazione. |
| TDD riduce la probabilità di avere bug nei test. |
I bug nei test sono difficili da tracciare rispetto a TDD. |
Scegliere tra TDD Vs BDD può essere molto complicato. Alcuni potrebbero obiettare che BDD è migliore per trovare bug, mentre altri potrebbero semplicemente dire che TDD offre una copertura del codice più elevata.
Nessuna delle due metodologie è migliore dell'altra. Dipende dalla persona e dal team di progetto decidere quale metodologia utilizzare.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
