Nel precedente articolo abbiamo spiegato cos’è il test driven development e quali vantaggi porta durante lo sviluppo di un’applicazione. Il Behaviour Driven Development (BDD) fa parte della filosofia agile e ha lo scopo di migliorare la comunicazione all’interno dell’intero team di un progetto.
Lo scopo del BDD è quello di fare in modo che il team di sviluppo comprenda appieno le richieste del cliente o dell’utilizzatore finale e che quest’ultimo sia a conoscenza di ciò che il team di sviluppo ha compreso. Spesso succede che il committente e gli sviluppatori abbiano punti di vista e background diversi. Questo provoca incomprensioni e succede che il committente richieda numerose modifiche in corso d’opera. Questo provoca ritardi e l’aumento del costo di produzione.
Durante il processo di sviluppo BDD le funzionalità vengono descritte con quello che si definiscono user stories e si definiscono i criteri di accettazione. Una volta che una user story è definita, ci si concentra sui possibili scenari in cui la funzionalità viene eseguita. Lo scenario di una user story rappresenta il test di accettazione una volta che lo sviluppo della funzionalità è completato.
Sia la descrizione della user story sia gli scenari vengono descritti in linguaggio naturale con una terminologia comprensibile da tutti i partecipanti al gruppo di lavoro, siano essi sviluppatori, responsabili marketing, project manager, ecc…
Given When e Then
Per descrivere uno scenario è importante seguire uno schema in tre step rappresentati da queste tre parole chiave: given, when e then.
- Dato un determinato contesto (given)
- Al verificarsi un determinato evento (when)
- Deve succedere che (then)
Given: rappresenta gli step necessari affinché il sistema raggiunga lo status corretto per la verifica del test
When: l’evento che deve avvenire per mezzo dell’utente per azionare la funzionalità in esame
Then: descrive cosa avviene nel sistema e quali sono le reazioni apprezzabili da parte dell’applicazione. E’ in questo momento che possiamo verificare se il test è passato o meno.
Facciamo un esempio pratico:
User story
Un utente può vendere azioni di borsa tramite il suo account.
Test di accettazione
Dato un account con 150 azioni di Apple inc.
Quando richiedo di venderne 50
Allora il mio account conterrà 100 azioni di Apple inc.
L’esempio è molto semplice, ma è importante per capire che i testi dovranno essere il più concisi e chiari possibile, facili da capire e che non siano soggetti ad interpretazione. Più avanti approfondiremo le user stories, come si definiscono, quali benefici portano e quali strumenti possiamo usare per organizzarle e tenerne traccia.
