In passato la gestione della qualità impiegava settimane a con­trol­la­re la fun­zio­na­li­tà di un software com­ple­ta­men­te svi­lup­pa­to. Oggi, grazie ai test au­to­ma­ti­ci, è possibile scoprire con la semplice pressione di un pulsante se un’ap­pli­ca­zio­ne complessa svolge i propri compiti senza problemi.

Una tecnica sempre più diffusa è il behavior-driven de­ve­lo­p­ment (sviluppo guidato dal com­por­ta­men­to), ab­bre­via­to in BDD. Questa forma di sviluppo software agile ha avuto origine dal test-driven de­ve­lo­p­ment (TDD) ed è con­si­de­ra­ta la sua esten­sio­ne logica. Con­tra­ria­men­te al TDD, in BDD il ri­spet­ti­vo software è con­si­de­ra­to prin­ci­pal­men­te dal punto di vista dell’utente. Tale approccio promuove una pro­get­ta­zio­ne più olistica del software e facilita la col­la­bo­ra­zio­ne tra svi­lup­pa­to­ri, re­spon­sa­bi­li della qualità e clienti.

Cos’è il behavior-driven de­ve­lo­p­ment?

Con la crescente com­ples­si­tà delle ap­pli­ca­zio­ni software, stanno emergendo sempre più metodi di gestione della qualità e dei test. Solo così è possibile con­trol­la­re in modo af­fi­da­bi­le la fun­zio­na­li­tà dei singoli com­po­nen­ti e in­di­vi­dua­re subito i difetti. Lo sviluppo guidato dai test o test-driven de­ve­lo­p­ment (TDD) è noto da tempo. In tale contesto gli svi­lup­pa­to­ri creano, pa­ral­le­la­men­te al software, dei test unitari o test di sistema ap­pro­pria­ti. Nel processo di pro­get­ta­zio­ne di un software, tuttavia, ha senso coin­vol­ge­re non solo i pro­gram­ma­to­ri ma anche i membri del team o le parti in­te­res­sa­te privi di co­no­scen­za tecnica del codice. Il behavior-driven de­ve­lo­p­ment (BDD) permette proprio questo.

Con lo sviluppo software agile, tutti i par­te­ci­pan­ti al progetto possono definire il com­por­ta­men­to de­si­de­ra­to dell’ap­pli­ca­zio­ne prima che il pro­gram­ma­to­re crei il testo sorgente. Questo accade sulla base di de­scri­zio­ni redatte in un lin­guag­gio fa­cil­men­te com­pren­si­bi­le per le persone. Ciò significa che anche il cliente, per il quale viene svi­lup­pa­to il software, assume una parte più attiva nella mo­del­la­zio­ne. BDD promuove quindi la col­la­bo­ra­zio­ne e assicura una re­di­stri­bu­zio­ne della re­spon­sa­bi­li­tà. Uti­liz­zan­do cor­ret­ta­men­te questo tipo di sviluppo software, evitate fin dall’inizio in­com­pren­sio­ni e generate ideal­men­te un prodotto finale di qualità superiore.

Come funziona esat­ta­men­te il BDD?

Come sug­ge­ri­sce il nome, il behavior-driven de­ve­lo­p­ment si basa sul com­por­ta­men­to che il ri­spet­ti­vo software dovrebbe mostrare. Grazie al co­sid­det­to lin­guag­gio ubiquo, ovvero al “lin­guag­gio co­mu­ne­men­te usato”, anche i di­let­tan­ti possono creare de­ter­mi­na­te de­scri­zio­ni com­por­ta­men­ta­li. Il lin­guag­gio ubiquo deriva dal domain-driven design (DDD), che, come il BDD, si concentra sul dominio dell’ap­pli­ca­zio­ne. Entrambi gli approcci tengono conto di tutte le aree coinvolte nella creazione del software e le combinano in­di­pen­den­te­men­te da framework, linguaggi di pro­gram­ma­zio­ne o strumenti. L’uso di un lin­guag­gio uniforme consente proprio questo.

No­no­stan­te tutto anche il behavior-driven de­ve­lo­p­ment richiede strumenti e framework. Affinché i casi di test definiti possano anche essere tradotti in un codice ese­gui­bi­le, è ne­ces­sa­rio seguire alcune regole. Ad esempio, le de­scri­zio­ni nel BDD non sono scritte in testo libero. Uti­liz­zan­do strumenti BDD come JBehave, Cucumber o Behat si segue una struttura definita che consente un’im­ple­men­ta­zio­ne corretta. L’uso di questi strumenti è molto più semplice dell’ap­pren­di­men­to di un lin­guag­gio di pro­gram­ma­zio­ne classico. Ecco la struttura ge­rar­chi­ca che seguite nor­mal­men­te nel behavior-driven de­ve­lo­p­ment:

  • Eseguite in­nan­zi­tut­to un’analisi dei requisiti in cui definite esat­ta­men­te i compiti, gli obiettivi e le fun­zio­na­li­tà del software. Quindi chiedete a voi stessi o al vostro cliente cosa dovrebbe fare il software.
  • Dopo avere iden­ti­fi­ca­to tutte le fun­zio­na­li­tà, queste vengono descritte sotto forma di scenari pre­de­fi­ni­ti. Provate a pensare a tutte le possibili si­tua­zio­ni in cui il software dovrebbe ri­spon­de­re con una risposta specifica.
  • Nel passaggio suc­ces­si­vo re­gi­stra­te la risposta prevista per ogni scenario nello schema “Assume-If-Then”. “Supposto” descrive il software prima del test, “Se” l’azione durante il test e “Allora” lo stato del software dopo il test.

Il vo­ca­bo­la­rio può variare leg­ger­men­te a seconda dello strumento BDD in uso. Invece di “Supposto” alcuni strumenti accettano anche for­mu­la­zio­ni come “Dato”. Per inciso, tali strumenti sono di­spo­ni­bi­li per i linguaggi di pro­gram­ma­zio­ne più comuni come Java, Ja­va­Script, Python o Ruby.

Un esempio di BDD

Im­ma­gi­na­te di voler svi­lup­pa­re un negozio online intuitivo. Una volta che il cliente si è re­gi­stra­to nel vostro negozio, i suoi dati utente devono essere salvati. Così potrà accedere più volte senza dover inserire nuo­va­men­te i suoi dati personali. Nel lin­guag­gio Gherkin am­pia­men­te usato, che viene uti­liz­za­to nello strumento BDD Cucumber, la sintassi corretta è la seguente:

Funzionalità: Un cliente esistente dovrebbe essere in grado di accedere al proprio account utente con i suoi dati di accesso
	Scenario: il cliente immette i dati di accesso corretti durante la procedura di login
		Supposto che ho un account utente valido
		E sono sulla pagina di login 
		Se inserisco il mio indirizzo e-mail nel campo e-mail 
		E inserisco la mia password associata nel campo password 
		E faccio clic sul pulsante di accesso 
		Allora dovrei accedere automaticamente

L’esempio sopra mostra che uti­liz­zan­do l’aggiunta “E” è possibile impostare diverse con­di­zio­ni e quindi rendere più complessi i casi di test.

Cosa distingue BDD da altri metodi di prova?

Nel testare un software il behavior-driven de­ve­lo­p­ment si occupa della domanda “Come“. Le parti in­te­res­sa­te vogliono sapere come testare cor­ret­ta­men­te il com­por­ta­men­to di un codice e non la sua im­ple­men­ta­zio­ne. Il co­sid­det­to test del modulo, invece, riguarda la corretta im­ple­men­ta­zio­ne di una singola unità di codice. Questo metodo di prova riguarda quindi il “Cosa” ed è un buon modo per trovare singoli bug. Il Test Driven De­ve­lo­p­ment, che si occupa del processo di ese­cu­zio­ne dei test, risponde alla domanda del “Se”. Questo processo può includere anche test di moduli o altri metodi di test.

N.B.

Oltre ai test dei moduli, ci sono anche i test di in­te­gra­zio­ne e di fun­zio­na­li­tà, che sono molto più complessi, perché ri­guar­da­no l’in­te­ra­zio­ne di diverse parti del sistema e la fun­zio­na­li­tà generale di un software.

La seguente tabella riassume bre­ve­men­te i vantaggi e gli svantaggi del behavior-driven de­ve­lo­p­ment:

Vantaggi Svantaggi
Il lin­guag­gio ubiquo ideale per i prin­ci­pian­ti, poiché non è richiesta alcuna co­no­scen­za pre­li­mi­na­re Spe­ci­fi­che scritte in modo ina­de­gua­to rendono difficile per gli svi­lup­pa­to­ri lavorare
Migliore co­mu­ni­ca­zio­ne tra svi­lup­pa­to­ri, parti in­te­res­sa­te e re­spon­sa­bi­li della qualità Il coin­vol­gi­men­to di più parti porta a tempi di sviluppo più lunghi
I casi di test servono come do­cu­men­ta­zio­ne vivace e possono essere fa­cil­men­te adattati La con­ver­sio­ne in un flusso di lavoro BDD comporta maggiori sforzi con i codici legacy
L’at­ten­zio­ne è rivolta agli utenti finali e alla facilità d’uso del software

Sebbene sia possibile uti­liz­za­re ogni metodo di prova sin­go­lar­men­te, la qualità del software mi­glio­re­rà con­si­de­re­vol­men­te se si uti­liz­za­no più metodi di prova in com­bi­na­zio­ne. Con BDD si definisce la procedura migliore per scrivere i test, mentre con TDD si assicura un'e­le­va­ta copertura dei test.

Vai al menu prin­ci­pa­le