Test Driven De­ve­lo­p­ment: ecco come funziona questo metodo

Con la crescente com­ples­si­tà dei programmi per computer, i metodi agili del Test Driven De­ve­lo­p­ment (TDD) stanno di­ven­tan­do sempre più popolari. E per una buona ragione: con TDD i pro­gram­ma­to­ri as­si­cu­ra­no che la pro­get­ta­zio­ne del software sia ben ponderata prima di iniziare a scrivere il codice funzione. Questa procedura non solo migliora in modo si­gni­fi­ca­ti­vo la qualità del software, ma riduce anche gli sforzi di ma­nu­ten­zio­ne.

Lo sviluppo basato sui test viene uti­liz­za­to tra l’altro nell’Extreme Pro­gram­ming, ca­rat­te­riz­za­to da revisioni, test, pro­get­ta­zio­ne e ri­pro­get­ta­zio­ne continui. Anche il Test Driven De­ve­lo­p­ment aderisce a un ciclo di sviluppo la cui sequenza deve essere ri­spet­ta­ta per un’im­ple­men­ta­zio­ne efficace.

Esistono da tempo vari metodi di test che con­trol­la­no la qualità del software. Tester in­di­pen­den­ti hanno ve­ri­fi­ca­to la fun­zio­na­li­tà dei programmi per computer nella gestione della qualità fin dall’inizio dello sviluppo del software. A quel tempo l’effettivo sviluppo del software e i metodi di prova erano ancora visti come processi in­di­pen­den­ti. L’approccio test-first è emerso solo con lo svi­lup­pa­to­re software sta­tu­ni­ten­se e fondatore dell’Extreme Pro­gram­ming Kent Beck. Questi ha sem­pli­ce­men­te invertito il processo pre­ce­den­te: invece di scrivere prima il codice sorgente e poi testarlo, il team di sviluppo scrive prima i test. Quindi utilizza i casi di test per scrivere e im­ple­men­ta­re il miglior codice possibile.

Anche se ini­zial­men­te lo sviluppo basato sui test può sembrare con­tro­in­tui­ti­vo agli occhi di un di­let­tan­te, ha cer­ta­men­te senso e porta a risultati migliori. Mentre le procedure di test con­ven­zio­na­li a valle uti­liz­za­no un modello a cascata o modello a V, i processi in TDD vengono eseguiti in un ciclo. Ciò significa che prima bisogna iden­ti­fi­ca­re i casi di test che spesso fal­li­sco­no. È una scelta de­li­be­ra­ta, perché nel secondo passaggio si scrive solo la quantità minima di codice ne­ces­sa­ria per superare i test. I com­po­nen­ti vengono quindi ri­fat­to­riz­za­ti: pur man­te­nen­do le sue funzioni, è possibile estendere o ri­strut­tu­ra­re il codice sorgente se ne­ces­sa­rio.

Il Test Driven De­ve­lo­p­ment si basa sui risultati dei casi di test spe­ci­fi­ca­ti. La procedura ciclica ga­ran­ti­sce che il codice sia tra­sfe­ri­to al sistema pro­dut­ti­vo solo quando tutti i requisiti software sono stati sod­di­sfat­ti. Ciò significa che i com­po­nen­ti del codice vengono ri­fat­to­riz­za­ti e nuo­va­men­te testati fino a quando il test non viene più vi­sua­liz­za­to come difettoso. Con questo metodo il software viene ar­ric­chi­to gra­dual­men­te con nuove funzioni, poiché dopo ogni test superato viene scritto un nuovo codice sorgente. Per questo motivo TDD è anche uno dei modelli di processo in­cre­men­ta­li nello sviluppo del software.

I singoli casi di test ge­ne­ral­men­te non sono sot­to­po­sti al ciclo per più di qualche secondo o minuto: in questo modo i risultati si ri­flet­to­no ra­pi­da­men­te nel codice pro­dut­ti­vo. Affinché l’ite­ra­zio­ne abbia luogo senza ulteriori sforzi, sono necessari uno strumento e un framework TDD. In genere, gli svi­lup­pa­to­ri uti­liz­za­no uno strumento di au­to­ma­zio­ne dello sviluppo come Crui­se­Con­trol o Jenkins. Questi con­sen­to­no l’in­te­gra­zio­ne continua e senza errori dei com­po­nen­ti nel codice sorgente. Anche JUnit, Maven e Ant sono popolari nello sviluppo di Java. In generale, i test sono sempre scritti nella stessa lingua del codice funzione. Per PHP ci sono strumenti come Ceedling o CMock.

Ma come funziona esat­ta­men­te la procedura di test? Il ciclo che i pro­gram­ma­to­ri seguono nel Test Driven De­ve­lo­p­ment è anche chiamato ciclo Red-Green-Refactor. Descrive le singole fasi da seguire per con­se­gui­re la massima ef­fi­cien­za:

1. Fase rossa: in questa fase im­me­de­si­ma­te­vi nel ruolo dell’utente che desidera usare il codice in modo semplice. Scrivete dunque un test che comprenda dei com­po­nen­ti che non sono ancora stati im­ple­men­ta­ti. Dovete pertanto decidere quali elementi sono veramente necessari per il fun­zio­na­men­to del codice.
2. Fase verde: sup­po­nia­mo che il test abbia esito negativo e sia evi­den­zia­to in rosso. Ora assumete il ruolo di un pro­gram­ma­to­re che cerca di trovare una soluzione semplice. Im­por­tan­te: scrivete solo la quantità minima di codice ne­ces­sa­ria e in­te­gra­te­la nel codice pro­dut­ti­vo, in modo che il test sia con­tras­se­gna­to con il verde.
3. Re­fac­to­ring: in questo passaggio il codice pro­dut­ti­vo viene let­te­ral­men­te “ripulito” e la sua struttura per­fe­zio­na­ta. Ciò significa che dovreste com­ple­tar­lo e ri­strut­tu­rar­lo in modo che sia elegante e com­pren­si­bi­le dal punto di vista dello svi­lup­pa­to­re. Eliminate ad esempio le du­pli­ca­zio­ni del codice e portatelo a livello pro­fes­sio­na­le.

As­si­cu­ra­te­vi che le singole attività non si so­vrap­pon­ga­no. Ciò significa che non dovete scrivere nessun test nella fase 2 e 3 e nessun codice pro­dut­ti­vo nella fase 1 e 3.

Il Test Driven De­ve­lo­p­ment è una strategia di pro­get­ta­zio­ne che guida il processo di sviluppo del software uti­liz­zan­do vari test. Con­tra­ria­men­te ai metodi di test a po­ste­rio­ri, i casi di test nel TDD fanno parte del progetto del software fin dall’inizio. I test, uti­liz­za­ti nell’ambito del TDD, dif­fe­ri­sco­no per scopo ed esten­sio­ne. Il test più semplice è lo unit testing, usato per testare i singoli com­po­nen­ti di un programma per computer. Più complessi sono i test di in­te­gra­zio­ne e fun­zio­na­li­tà, uti­liz­za­ti per ve­ri­fi­ca­re l’in­te­ra­zio­ne di diverse parti del sistema e la fun­zio­na­li­tà generale del software.

Alcuni anni fa, dal TDD si è svi­lup­pa­to il Behavior Driven De­ve­lo­p­ment (BDD). Qui il team di sviluppo ini­zial­men­te non si concentra sulla cor­ret­tez­za del codice, ma sul com­por­ta­men­to che si desidera dal software. Il vantaggio è che non è ne­ces­sa­rio avere una co­no­scen­za tecnica del codice per scrivere i casi di test e quindi è possibile coin­vol­ge­re nello sviluppo le parti in­te­res­sa­te e i re­spon­sa­bi­li della qualità. In linea generale si può dire che BDD definisce il modo migliore per scrivere i test, mentre TDD ga­ran­ti­sce un’ar­chi­tet­tu­ra pulita.

La seguente tabella riassume bre­ve­men­te i vantaggi e gli svantaggi dello sviluppo guidato dai test:

Sebbene sia possibile uti­liz­za­re i diversi metodi di prova sin­go­lar­men­te, com­bi­nan­do metodi di sviluppo basati su test e com­por­ta­men­ti si ottiene un software di qualità superiore, con maggior sod­di­sfa­zio­ne dell’utente finale.