Cos’è il BDD?
Il Behavior Driven Development (BDD) è un processo di sviluppo software Agile che incoraggia la collaborazione tra sviluppatori, QA e partecipanti non tecnici o aziendali a un progetto software.
Incoraggia i team a utilizzare conversazioni ed esempi concreti per formalizzare una comprensione condivisa del comportamento dell’applicazione.
Il concetto principale alla base del BDD è la cooperazione tra tutte le parti interessate di un progetto, al fine di condividere la definizione di un insieme di funzionalità e il loro comportamento attraverso una serie di esempi concreti.
Da questo punto di vista, il BDD come pratica che coinvolge sia gli utenti tecnici che quelli aziendali è strettamente legato ai principi della metodologia Agile.
Colmare il Gap: prospettiva di Business Vs. prospettiva degli sviluppatori
Consideriamo lo scenario esistente prima che il BDD emergesse come pratica. Come gli sviluppatori sanno, il processo di traduzione dei requisiti del software in una serie di specifiche di funzionalità ben definite è noioso, frustrante e soggetto a errori. Un documento di requisiti software era la tipica interazione tra utenti aziendali e sviluppatori quando era in vigore la metodologia waterfall. Si tratta in genere di un’interazione di tipo statico: gli utenti scrivono i requisiti e gli sviluppatori ne estraggono un insieme di funzionalità da implementare.
I documenti dei requisiti software possono contenere molti dettagli inutili, molte descrizioni contraddittorie delle stesse funzionalità e anche molte definizioni insufficienti di altre funzionalità. Gli sviluppatori devono quindi chiedere agli utenti aziendali di integrare il documento più volte, ma ogni versione del documento non è una mappatura 1 a 1 con l’insieme delle funzionalità da implementare.
La prima cosa da notare è che il processo di estrazione di funzionalità ben definite da questo tipo di documento è soggetto a errori; pertanto, non c’è alcuna garanzia di coprire tutte le funzionalità né di definirle correttamente.
Il processo di estrazione può produrre un divario considerevole e non accettabile tra il punto di vista degli utenti aziendali e quello degli sviluppatori.
Questo divario è dovuto principalmente al fatto che chi crea i documenti dei requisiti software e chi li usa per creare le funzionalità sono due team distinti. Se consideriamo che la QA è un altro team, allora capiamo facilmente che questo processo è piuttosto problematico.
Il BDD, come pratica per incoraggiare la collaborazione tra persone con culture e mentalità diverse, che insieme esplorano e definiscono il comportamento delle funzionalità, è un modo per colmare questa lacuna.
BDD come modo di descrivere le Features
Il punto centrale del BDD è la condivisione di strumenti e competenze tra soggetti tecnici e non tecnici, al fine di condividere i concetti e raggiungere una comprensione comune di un insieme di funzionalità.
Il primo strumento che possiamo utilizzare è il linguaggio: gli esempi concreti che descrivono il comportamento desiderato del sistema sono scritti in un linguaggio che è molto vicino al linguaggio naturale, quindi nel dominio degli utenti aziendali.
Il BDD si basa su un processo iterativo in tre fasi, dove le fasi sono: Scoperta, Formulazione e Automazione:
1. Scoperta
Il BDD aiuta i team ad avere le conversazioni giuste al momento giusto, in modo da ridurre al minimo il tempo dedicato alle riunioni e massimizzare la quantità di codice di valore prodotto.
In questa fase i membri del team, utenti tecnici e non, discutono dei requisiti relativi a una o più funzionalità (user story), al fine di ottenere una comprensione condivisa del comportamento atteso attraverso una serie di esempi concreti che descrivono come il sistema dovrebbe funzionare in diversi scenari.
Questa fase si basa su conversazioni strutturate chiamate discovery workshop, in cui i membri del team si concentrano su esempi del mondo reale che descrivono le funzionalità dal punto di vista dell’utente.
2. Formulazione
In questa fase ogni esempio viene espresso in un modo che possa essere documentato e poi verificato. Il metodo consiste nell’esprimere tali esempi utilizzando un mezzo che possa essere letto sia dagli esseri umani che dai processi automatizzati.
Un linguaggio ampiamente adottato è il gherkin: è simile a un linguaggio naturale e permette di descrivere le caratteristiche attraverso uno o più scenari.
Ogni scenario è un esempio concreto che spiega come la caratteristica dovrebbe comportarsi in una particolare circostanza.
Uno scenario tipico può essere espresso in gherkin descrivendo tre cose: 1) quali sono le precondizioni da soddisfare prima di iniziare a usare una funzionalità, 2) quali sono le azioni da compiere per usare la funzionalità, 3) e infine quali sono le asserzioni per verificare se la funzionalità è implementata correttamente.
Ecco la struttura di un tipico scenario BDD:
Data una precondizione
E un’altra precondizione
E…
Quando faccio qualcosa
E qualcos’altro
E…
Allora mi aspetto qualcosa
E qualcos’altro
E…
Ecco un esempio di definizione in gherkin della funzione relativa al prelievo di denaro tramite bancomat:
3. Automazione
In questa fase si prende uno scenario alla volta e si realizza un test che soddisfa le precondizioni (espresse nella clausola Given ), esegue le azioni (espresse nella clausola when ) e verifica le asserzioni (espresse nella clausola then).
Il test è un modo automatizzato per verificare se una funzionalità si comporta come descritto nello scenario corrispondente.
Come avviene nel TDD, il test viene realizzato prima dell’implementazione: si tratta quindi di un test che fallisce all’inizio, e poi si implementa la funzionalità per farla passare.
Dal momento che questo tipo di test è definito da un team di cui fanno parte persone del mondo del lavoro, ha un valore commerciale riconosciuto; pertanto, può essere utilizzato come parte dei test di accettazione.
Il BDD è supportato da diversi strumenti open source e commerciali; alcuni di questi sono:
Cucumber
https://cucumber.io/
JBehave
https://jbehave.org/
Nell’esempio seguente si può vedere come possono essere implementati i test relativi al primo scenario della funzione ATM:
Come si può vedere dall’esempio seguente, il processo di automazione produce una serie di report molto utili ai membri del team per verificare, durante tutte le fasi dello sviluppo, se le funzionalità sono state implementate, se si comportano come previsto o se, per qualche motivo, devono essere approfondite (nel caso in cui un refactoring o qualche altra modifica ne abbia danneggiato alcune).
Un altro punto chiave è che il BDD può essere visto come una sorta di documentazione: infatti, spiega quali sono le caratteristiche, come dovrebbero comportarsi e come è possibile verificarle.
BDD con TDD
Il BDD non sostituisce il TDD. La fase di automazione produce un insieme di test automatizzati, ma rispetto a quelli creati con il TDD, si trovano a un livello di astrazione superiore: vengono infatti utilizzati per verificare uno scenario relativo a una funzionalità o a una storia utente.
Un test BDD guiderà l’implementazione di una funzionalità nel suo complesso e il modo in cui soddisfare le aspettative descritte nel relativo scenario. La fase di implementazione di una singola funzionalità coinvolge molti componenti di basso livello e, abbracciando le pratiche TDD, tale implementazione inizierà con un test unitario fallito di un piccolo componente; quindi, il componente verrà implementato, dando luogo a un test verde. Il ciclo si ripete poi per altri componenti, come descritto nell’immagine seguente:
Poiché ogni caratteristica è costituita da molti piccoli componenti, ogni test BDD corrisponde a molti test TDD.
Sia il BDD che il TDD sono processi iterativi: partono da un test che fallisce, poi l’implementazione avrà l’effetto collaterale di correggere il test e, quando un refactoring fa fallire un test, l’iterazione ricomincerà.
TDD Vs. BDD
I test BDD fanno parte di una comprensione condivisa di un insieme di funzionalità tra tutti gli stakeholder di un progetto; hanno un valore commerciale riconosciuto e possono essere utilizzati come test di accettazione per verificare se il sistema si comporta come previsto.
Possono essere usati per decidere se è sicuro installarlo in produzione (go / no go); in genere, possono dire se qualcosa è rotto, ma non esattamente cosa.
I test TDD fanno parte del processo di sviluppo, sono utili agli sviluppatori per acquisire fiducia nella qualità del software e anche per fare refactoring senza la paura di rompere qualcosa, ma non hanno un valore di business immediatamente comprensibile.
I test TDD possono dire esattamente quale piccolo pezzo del software è rotto ma, quando uno di questi test fallisce, di solito è sicuro da installare in produzione.
Conclusioni
Sebbene i test siano una parte fondamentale, definire il BDD come una pratica di test è altamente riduttivo.
Il BDD è intimamente legato al concetto di Agile: con le sue procedure e i suoi strumenti, facilita la collaborazione tra persone con background e ruoli diversi, al fine di definire un punto di vista comune sulle funzionalità da implementare.
Il BDD consente di verificare il corretto comportamento del software in qualsiasi momento del processo di sviluppo e aiuta a fornire una documentazione strutturata sul funzionamento del software.
BDD e TDD non sono in competizione tra loro: ogni pratica completa l’altra ed è un aspetto fondamentale del processo di sviluppo.
References
https://gojko.net/2020/03/17/sbe-10-years.html
Autore: Massimo Da Roshttps://www.linkedin.com/in/massimodaros71/, Lead Software Engineer @ Bitrock
