Cosa è il Test-driven development e come può aiutarci nei processi di sviluppo?

Che cos’è il TDD e come può essere d’aiuto nei processi di sviluppo?

Ci sono molte risorse e libri su questo argomento, ma vorrei cercare di spiegarlo con un semplice esempio pratico. Probabilmente i puristi di questo metodo troveranno la spiegazione incompleta (mi scuso per questo), ma credo che sia sufficiente per imparare e capire i concetti base.

Inizierò con la definizione di Wikipedia:

Il test-driven development (abbreviato in TDD), in italiano sviluppo guidato dai test o sviluppo guidato dalle verifiche, è un modello di sviluppo del software che prevede che la stesura dei test automatici avvenga prima di quella del software che deve essere sottoposto a test, e che lo sviluppo del software applicativo sia orientato esclusivamente all’obiettivo di passare i test automatici precedentemente predisposti. Più in dettaglio, il TDD prevede la ripetizione di un breve ciclo di sviluppo in tre fasi, detto “ciclo TDD”.

Chiaro?

L’obiettivo principale del TDD è creare una strategia dove i test guidano lo sviluppo per renderlo più efficiente, produttivo e diminuendo le regressioni.

Questo metodo ci insegna a lavorare con parti di codice più piccole, farle funzionare, e infine integrare insieme tutte le parti (già funzionanti).

I benefici del TDD

L’introduzione del TDD sarà un punto di svolta per la tua esperienza di sviluppo.

Ecco una breve lista dei benefici più importanti:

1. Focus sui punti più importanti: ti verrà richiesto di scomporre il problema in piccole parti, questo ti aiuterà a mantenere l’attenzione sulle cose più importanti. Il pre-requisito è proprio scomporre un grosso task in piccoli passi e sviluppare tramite unit test.
2. Gestire compiti più semplici: lavorando su singoli task si semplifica la risoluzione dei problemi e si accelera il processo di sviluppo. Non ti ritroverai, dopo aver scritto tutto il codice, a scoprire che qualcosa non va e non sapere perché.
3. Integrazione semplificata: quando le singole parti del progetto saranno completate, metterle insieme sarà un vero piacere. In caso di regressione saprai in anticipo in quale parte del codice si nasconde l’errore.
4. Test gratis: una volta che il task è terminato, rimangono a capitale tanti unit test che possono essere usati come base di partenze per altri unit test ed integration test, utili per migliorare la qualità del codice ed evitare regressioni.

Cosa non è il TDD

TDD è un grande metodo, ma non è:

• una sostituzione dei test (unit test, acceptance test, ui test)
• qualcosa che puoi imparare in un giorno
• qualcosa che scrive codice al posto tuo
• una magia che tiene lontani i bug dal tuo codice

Il ciclo TDD

Il TDD è composto principalmente da tre fasi:

1. Write the unit test (RED)
2. Make it work (GREEN)
3. Refactor

Ad esempio, si scrive un test automatico, usando il codice all’interno per implementare la funzione finchè passa i test, quindi si esegue il refactoring posizionando questo pezzo di codice dove serve.

Limiti

In molti casi è difficile sviluppare un test che riproduca una reale funzione del codice.

E’ adatto per procedure semplici , ma quando andiamo a coinvolgere il database o la UI la difficoltà di scrivere test aumenta e in molti casi l’effort supera i possibili vantaggi.

Ci sono alcune best practices e librerie che ci aiutano per risolvere queste problematiche, ma in generale non è facile testare tutte le parti dell’applicazione usando un semplice test.

Che cos’è il BDD

BDD è uno sviluppo del TDD che entra in gioco in situazioni nelle quali il test è limitante.

Questa estensione usa lo sviluppatore come test, mantenendo la filosofia del BDD. Puoi comunque scomporre un compito complesso in altri più piccoli, testando il comportamento dell’utente con gli stessi vantaggi del TDD nei compiti di backend.

I requisiti del TDD

Quando si lavora in team tutti i membri del gruppo devono conoscere e condividere questa filosofia, oltre a conoscere tutta la tecnologia coinvolta.

Prima di tutto il codice deve essere verificato da un efficace sistema di test:

• .net, .net core: costruiti su Visual Studio o xunit (il secondo è il mio preferito)
• java: junit funziona molto bene, non ho avuto bisogno di cercare alternative
• php: il test php ha funzionato in tutti i casi

Poi è fondamentale avere un’architettura che permetta di fingere o ricreare il comportamento corretto durante il test.

Sto parlando di un ORM che può funzionare in memoria o su un database locale durante il test, ma anche da usare come service o repository pattern.

Può aiutare anche usare una libreria DI (quella integrata in .net core, autofac o qualsiasi altra…).

Per ultimo è importante aver prototipato un buon processo di sviluppo, con continuous integration, oltre ad una corretta configurazione per definire quali test conviene eseguire durante l’integrazione e quali vanno eseguiti solo localmente.

Conclusione

La TDD è una metodologia che guida il processo di sviluppo supportato dai test.

Ciò aiuta la codifica in molti modi, ma richiede che tutti i membri del team abbiano alcune nozioni di base.

Una volta eseguito questo passaggio, gestirai un compito più semplice e avrai molti test che potranno essere riutilizzati.

Questo processo aiuterà ad evitare la regressione e raggiungere l’obiettivo più rapidamente, nonostante lo sforzo di scrivere unità test durante lo sviluppo.

Inoltre, se l’applicazione è difficile da testare a causa della complessità, è possibile mantenere la stessa filosofia usando il metodo BDD.