Test Driven Development: ecco come funziona questo metodo

Con la crescente complessità dei programmi per computer, i metodi agili del Test Driven Development (TDD) stanno diventando sempre più popolari. E per una buona ragione: con TDD i programmatori assicurano che la progettazione del software sia ben ponderata prima di iniziare a scrivere il codice funzione. Questa procedura non solo migliora in modo significativo la qualità del software, ma riduce anche gli sforzi di manutenzione.

Lo sviluppo basato sui test viene utilizzato tra l’altro nell’Extreme Programming, caratterizzato da revisioni, test, progettazione e riprogettazione continui. Anche il Test Driven Development aderisce a un ciclo di sviluppo la cui sequenza deve essere rispettata per un’implementazione efficace.

Esistono da tempo vari metodi di test che controllano la qualità del software. Tester indipendenti hanno verificato la funzionalità 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 indipendenti. L’approccio test-first è emerso solo con lo sviluppatore software statunitense e fondatore dell’Extreme Programming Kent Beck. Questi ha semplicemente invertito il processo precedente: 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 implementare il miglior codice possibile.

Anche se inizialmente lo sviluppo basato sui test può sembrare controintuitivo agli occhi di un dilettante, ha certamente senso e porta a risultati migliori. Mentre le procedure di test convenzionali a valle utilizzano un modello a cascata o modello a V, i processi in TDD vengono eseguiti in un ciclo. Ciò significa che prima bisogna identificare i casi di test che spesso falliscono. È una scelta deliberata, perché nel secondo passaggio si scrive solo la quantità minima di codice necessaria per superare i test. I componenti vengono quindi rifattorizzati: pur mantenendo le sue funzioni, è possibile estendere o ristrutturare il codice sorgente se necessario.

Il Test Driven Development si basa sui risultati dei casi di test specificati. La procedura ciclica garantisce che il codice sia trasferito al sistema produttivo solo quando tutti i requisiti software sono stati soddisfatti. Ciò significa che i componenti del codice vengono rifattorizzati e nuovamente testati fino a quando il test non viene più visualizzato come difettoso. Con questo metodo il software viene arricchito gradualmente con nuove funzioni, poiché dopo ogni test superato viene scritto un nuovo codice sorgente. Per questo motivo TDD è anche uno dei modelli di processo incrementali nello sviluppo del software.

I singoli casi di test generalmente non sono sottoposti al ciclo per più di qualche secondo o minuto: in questo modo i risultati si riflettono rapidamente nel codice produttivo. Affinché l’iterazione abbia luogo senza ulteriori sforzi, sono necessari uno strumento e un framework TDD. In genere, gli sviluppatori utilizzano uno strumento di automazione dello sviluppo come CruiseControl o Jenkins. Questi consentono l’integrazione continua e senza errori dei componenti 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 esattamente la procedura di test? Il ciclo che i programmatori seguono nel Test Driven Development è anche chiamato ciclo Red-Green-Refactor. Descrive le singole fasi da seguire per conseguire la massima efficienza:

1. Fase rossa: in questa fase immedesimatevi nel ruolo dell’utente che desidera usare il codice in modo semplice. Scrivete dunque un test che comprenda dei componenti che non sono ancora stati implementati. Dovete pertanto decidere quali elementi sono veramente necessari per il funzionamento del codice.
2. Fase verde: supponiamo che il test abbia esito negativo e sia evidenziato in rosso. Ora assumete il ruolo di un programmatore che cerca di trovare una soluzione semplice. Importante: scrivete solo la quantità minima di codice necessaria e integratela nel codice produttivo, in modo che il test sia contrassegnato con il verde.
3. Refactoring: in questo passaggio il codice produttivo viene letteralmente “ripulito” e la sua struttura perfezionata. Ciò significa che dovreste completarlo e ristrutturarlo in modo che sia elegante e comprensibile dal punto di vista dello sviluppatore. Eliminate ad esempio le duplicazioni del codice e portatelo a livello professionale.

Assicuratevi che le singole attività non si sovrappongano. Ciò significa che non dovete scrivere nessun test nella fase 2 e 3 e nessun codice produttivo nella fase 1 e 3.

Il Test Driven Development è una strategia di progettazione che guida il processo di sviluppo del software utilizzando vari test. Contrariamente ai metodi di test a posteriori, i casi di test nel TDD fanno parte del progetto del software fin dall’inizio. I test, utilizzati nell’ambito del TDD, differiscono per scopo ed estensione. Il test più semplice è lo unit testing, usato per testare i singoli componenti di un programma per computer. Più complessi sono i test di integrazione e funzionalità, utilizzati per verificare l’interazione di diverse parti del sistema e la funzionalità generale del software.

Alcuni anni fa, dal TDD si è sviluppato il Behavior Driven Development (BDD). Qui il team di sviluppo inizialmente non si concentra sulla correttezza del codice, ma sul comportamento che si desidera dal software. Il vantaggio è che non è necessario avere una conoscenza tecnica del codice per scrivere i casi di test e quindi è possibile coinvolgere nello sviluppo le parti interessate e i responsabili della qualità. In linea generale si può dire che BDD definisce il modo migliore per scrivere i test, mentre TDD garantisce un’architettura pulita.

La seguente tabella riassume brevemente i vantaggi e gli svantaggi dello sviluppo guidato dai test:

Sebbene sia possibile utilizzare i diversi metodi di prova singolarmente, combinando metodi di sviluppo basati su test e comportamenti si ottiene un software di qualità superiore, con maggior soddisfazione dell’utente finale.