Che cos’è lo sviluppo guidato dai test? O TDD?

Che cos’è lo sviluppo guidato dai test? O TDD?

Test Driven Development o TDD, come è affettuosamente noto nei circoli degli sviluppatori, è un aspetto importante del processo di sviluppo del software. Attraverso questo approccio, è più facile testare le prestazioni di un codice specifico. Vengono creati casi di test per ogni funzionalità dell’applicazione software e, quando una particolare funzionalità non riesce in un test, il codice viene rielaborato e vengono creati nuovi codici. Il nuovo codice dovrebbe anche superare il test ed essere privo di bug. Lo sviluppatore deve scrivere un nuovo codice solo se il test automatizzato per il codice non è riuscito, quindi ci sarà un test case per ogni funzionalità, per quanto piccola possa essere. E TDD riguarda la progettazione e lo sviluppo di test per ogni singola funzionalità dell’applicazione.

Il nome Test Driven Development indica che è il processo di fare i test nel modo giusto che guida lo sviluppo del software. Quindi, il processo stesso trae le sue radici dalla metodologia Agile e dalla programmazione Extreme. Questo processo garantisce che gli sviluppatori creino e mantengano un codice resiliente ea lungo termine.

Quindi il processo per TDD sarebbe scrivere prima il test dell’unità e, se il test fallisce, implementare le modifiche al codice. Questo aiuta anche a evitare la duplicazione del codice. Il tutto si basa sulla scrittura e sulla correzione di test falliti prima dello sviluppo effettivo. Tuttavia, affinché il TDD funzioni correttamente, sarebbe consigliabile scrivere i casi di test in casi di test semplici. Per una logica aziendale complessa, sarebbe davvero difficile scrivere una combinazione di casi di test e ottenere il pieno successo. C’è la possibilità che tu possa perdere la scrittura di alcuni test, quindi non è affatto un compito facile.

Differenza tra TDD e test tradizionale

I test tradizionali richiedono più tempo rispetto a TDD e si basano sulla ripetizione di un breve ciclo di sviluppo. Prima viene scritto il test dall’inizio, quindi viene scritto il codice del programma, seguito dal comportamento desiderato del sistema. Al superamento della prova scritta (verifica della correttezza del lavoro del codice non scritto), viene eseguito il refactoring del codice scritto.

Inizialmente, anche TDD richiederà molto tempo, ma nel tempo lo sviluppatore si abituerà perché il processo di sviluppo diventerà più strutturato. Ad esempio, quando assumi uno sviluppatore, deciderà cosa scrivere e poi come scriverlo.

Il test tradizionale ha successo quando trova correttamente uno o più difetti. Proprio come TDD. Trovare i difetti è in realtà un buon segno perché allora sai che devi risolvere ciò che non va e andare avanti da lì. TDD ti dà anche più fiducia quando rilasci il programma e assicura che soddisfi i requisiti per i quali è definito.

Nei test tradizionali, l’attenzione si concentra maggiormente sulla progettazione dei casi di test, mentre in TDD l’attenzione si concentra maggiormente sul codice di produzione per verificare se il test funzionerà secondo i piani.

TDD ti offre una copertura del test del 100%, in cui il test viene eseguito per ogni singola riga di codice, non è il caso dei test tradizionali.

Quando l’ambito del progetto è davvero ampio, devi essere molto accurato durante lo svolgimento dei test. E c’è la possibilità che i test subiscano ritardi e superino i limiti di budget e tempo.

TDD potrebbe essere difficile da scrivere e potrebbe rallentare i tempi di sviluppo, ma sicuramente pagherebbe nel lungo periodo.

Un altro svantaggio di TDD è che il concetto è difficile da applicare al codice legacy esistente.

È sempre bene che il test fallisca prima di rilasciare un progetto, perché così saprai di aver eseguito un test valido. Attraverso TDD, saprai che il tuo sistema soddisfa i requisiti per i quali è stato progettato. Quindi l’attenzione si concentra maggiormente sul codice di produzione per TDD, in quanto garantisce che il test funzioni correttamente. E quando il software soddisfa tutti i requisiti progettati per esso.

Le diverse fasi di uno sviluppo guidato da test

Ci sono tre diverse fasi di TDD: Rosso, Verde e Refactor

Seguire questo ordine di passaggi assicura di avere test per il codice che stai scrivendo, quindi devi scrivere i codici solo per quei test che stai facendo.

Il palco rosso

L’idea della fase rossa è di far fallire il test, e anche la fase più difficile perché si sviluppa deve scrivere il test senza codice. I nuovi sviluppatori devono trovarlo difficile perché sarebbero confusi su cosa testare senza avere il codice per esso. Ma è una cosa abituale e con l’esperienza diventerà liscia. Il primo test viene scritto senza scrivere codice e per dichiarare classe e metodo e il test avrà un errore di compilazione. Il prossimo passo sarebbe correggere l’errore di compilazione ed eseguire il test per fallirlo. Questo provoca la bandiera rossa.

La fase verde

Dopo la fase rossa, il passo successivo sarebbe scrivere il codice. Questo codice dovrà superare il primo test. Scrivere abbastanza codice per garantire che solo il primo test passi, è un ostacolo che molti sviluppatori devono affrontare inizialmente. Perché nel prossimo test, dovrebbe fallire, seguito da un nuovo codice per superarli.

La fase del rifrattore

Nelle prime due fasi, in cui il test deve prima fallire e poi passare, l’obiettivo era quello di far passare poi i test. Ma nella fase Refractor, dovranno essere considerati altri fattori come la qualità del codice, la manutenibilità del codice, la leggibilità del codice ecc. L’attenzione qui è quindi su quegli aspetti, quindi i test unitari si concentreranno su quelli. Nella fase di refactoring, non devi preoccuparti dell’aspetto della funzionalità mancante, perché quando si verificano le modifiche al codice, i casi di test si conformeranno automaticamente anche alla parte di funzionalità.

TDD si adatta bene alla metodologia Agile

È abbastanza ovvio che i requisiti del progetto possono cambiare bene nella fase di sviluppo, quindi avere TDD in collaborazione con lo sviluppo Agile lo renderà sicuramente di successo e costruirà progetti in linea con i requisiti del cliente. Con lo sviluppo guidato dai test, ottieni un feedback anticipato sul progetto su cui puoi lavorare facilmente.

Aiuterebbe anche ad anticipare e ridurre i colli di bottiglia critici e garantire che il progetto proceda come previsto. I team di sviluppatori possono risparmiare molto tempo poiché i test vengono creati molto prima nello sviluppo del progetto e non devono preoccuparsi di script di test estesi.

Conclusione

Il Test Driven Development è una tecnica che richiede molto tempo, ma è preziosa nel senso che ti aiuterà a guidare il tuo progetto nella giusta direzione ottenendo un feedback corretto sul progetto e rilevando i bug. Tuttavia, è un’opzione molto migliore rispetto ai test tradizionali in quanto richiede più tempo e denaro.

Link interessanti:

Test Driven Development: cos’è e cosa non è.

Maggiori informazioni sullo sviluppo basato sui test

Immagini: Canvas

L’autore: Sascha Thattil lavora presso Software-Developer-India.com che fa parte del gruppo YUHIRO. YUHIRO è un’impresa tedesco-indiana che fornisce programmatori ad aziende IT, agenzie e dipartimenti IT.