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).
L’introduzione del TDD sarà un punto di svolta per la tua esperienza di sviluppo.
Ecco una breve lista dei benefici più importanti:
TDD è un grande metodo, ma non è:
Il TDD è composto principalmente da tre fasi:
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.
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.
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.
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:
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.
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.