Sviluppo: Test Driven vs Behavioural Driven (tdd bdd)
Nel mondo dello sviluppo software, è naturale sentire parlare del binomio tdd bdd. Con TDD, acronimo di Test Driven Development, si inquadra un processo di sviluppo che si basa sulla stesura di test automatici. La suddetta, deve avvenire prima di quella del software stesso, che deve essere sottoposto a procedure di testing.
Fondamentale inoltre è che lo sviluppo del software sia orientato al superamento di specifici test automatici precedentemente predisposti. Per entrare maggiormente nello specifico, è il caso di ricordare che il TDD si divide in quattro parti: analisi, design, sviluppo e testing.
Gli sviluppatori, in poche parole, osservano il dominio del problema e lo analizzano, per trovare poi le applicazioni adatte per risolverlo. Queste ultime, ovviamente, devono essere sottoposte a una procedura di testing.
I passi da seguire per concretizzare l’intero processo sono i seguenti:
- λ Scrittura di un unit test destinato al fallimento: in questo caso, il risultato del lavoro dello sviluppatore deve essere il più semplice possibile. Fondamentale è che sia destinato a fallire. Lo sviluppatore, infatti, deve indicare come non dovrebbe comportarsi il codice.
- λ Esecuzione del test: nel momento in cui le procedure di testing falliscono, arriva il momento di scrivere il codice minimo per farli passare. In questa fase, è cruciale non aggiungere nuovi elementi.
- λ Miglioramento del test: lo sviluppatore che ritiene di poter ottimizzare il codice che ha scritto, può farlo ed eseguire nuovi test. Una volta raggiunto un risultato ottimale, non resta che iniziare a creare nuovi unit test e andare avanti.
Caratterizzato da vantaggi che riguardano la possibilità di riutilizzare il codice e di lavorare in gruppo, il TDD si contrappone spesso al BDD, acronimo per Behaviour Driven Development.
Cos’è il Behaviour Driven Development?
Vediamo ora il secondo polo del binomio tdd bdd. Il Behaviour Driven Development. Parte della filosofia agile, ha lo scopo di ottimizzare la comunicazione tra i professionisti che si occupano di un determinato progetto di sviluppo.
Nel corso del processo di BDD, le funzionalità vengono descritte tramite le cosiddette user stories. Le suddette sono composte da:
- λ Una descrizione testuale finalizzata alla pianificazione o utilizzabile come promemoria.
- λ Una conversazione avente come obiettivo quello di approfondire eventuali aspetti non chiari.
- λ Un test finalizzato a verificare se la story è completa o no.
Fondamentale è che la descrizione sia concisa, redatta con un linguaggio naturale e in grado di attenersi a una specifica funzionalità. Essenziale infine è che non contenga aspetti tecnici.
Una volta completata la story, arriva il momento di concentrarsi sui possibili scenari di esecuzione della funzionalità. Lo scenario delle singole user stories costituisce il vero e proprio test di accettazione da considerare dopo la fine dello sviluppo della funzionalità.
La descrizione dello scenario deve essere gestita considerando tre step, che sono riassumibili con i termini given, when e then. I dettagli in merito sono i seguenti:
- λ Dato uno specifico contesto (given)
- λ Se si verifica un determinato evento (when)
- λ Deve succedere una cosa specifica (then)
Nello step given, vengono inclusi i passi tecnici necessari affinché il sistema arrivi allo status corretto per eseguire il test. Per quel che concerne lo step when, invece, ricordiamo che si parla di un evento che deve avvenire per mezzo di un utente, con lo scopo di azionare la funzionalità sotto esame.
Parliamo infine dello step then, fondamentale per comprendere il secondo punto del binomio tdd bdd e caratterizzato da una descrizione di quello che avviene nel sistema, con un focus sulle reazioni apprezzabili dalla singola applicazione. In tale fase, lo sviluppatore capisce se il test è stato passato o meno.
