Articoli di programmazione
Breve introduzione al Test Driven Development
Come il TDD può aiutarti nello sviluppo delle applicazioni. Una buona pratica di progettazione che comporta tanti vantaggi nello sviluppo e nella manutenzione di ogni applicazione.
Il Test Driven Development, in Italiano Sviluppo Guidato dai Test, è una pratica di #programmazione che pone alla propria base la scrittura di test automatici. L'attività di implementazione è esclusivamente finalizzata a far funzionare i test precedentemente predisposti. Di fatto rientra nella categoria delle tecniche di progettazione del software, ma i suoi benefici ricadono in altri ambiti.
Il #TDD richiede la ripetizione di un piccolo ciclo, appunto ciclo TDD, che si basa su 3 fasi:
1) Fase rossa: si scrive un test per una funzionalità del #software e, siccome la funzionalità non è ancora stata implementata, il test ovviamente fallisce
2) Fase verde: si scrive il codice applicativo necessario a far passare il test
3) Refactoring: si esegue refactoring sul codice scritto nella fase verde. E' in questa fase che si cerca di ottimizzare il codice.
Il TDD ci chiede di sviluppare il codice partendo già dal risultato che si vuole ottenere. Questa metodologia di codifica, benchè alle prime esperienze possa sembrare disorientante, di fatto comporta enormi vantaggi a più livelli:
- Visto che prima di ogni porzione di codice applicativo si scrive il relativo Test, teoricamente l'applicazione è completamente testata, quindi il Code Coverage applicativo è molto alto. Questo è un vantaggio per l'applicazione stessa quindi per il cliente in primis, che avrà un prodotto di qualità tendenzialmente bug free.
- Il tempo speso a fare #Debug si riduce enormemente perchè di fatto la maggior parte del Debug lo faranno i test per noi. Questo è un vantaggio per lo sviluppatore perchè può ottimizzare il proprio tempo ed evitare di spendere giornate per trovare quel fastidiosissimo bug.
- Scrivere e testare una funzionalità per volta spinge il programmatore a separare bene le varie responsabilità e ad aderire al Single Responsibility Principle (principio di singola responsabilità) per cui ogni classe, metodo e variabile deve avere una ed una sola responsabilità. L'applicazione finale sarà semplicemente migliore.
- Similarmente al punto precedente, il TDD spinge verso il Loose Coupling(accoppiamento debole), per cui ogni classe non dipende dalle altre ma è anzi indipendente e permette di essere sostituita agilmente senza danneggiare l'intero sistema. Progettare e sviluppare in TDD ci spinge prepotentemente verso una architettura modulare, con #IOC e #Dependency Injection ed un sistema estremamente disaccoppiato. Questo aspetto, è quello che giudico personalmente il più grande vantaggio del TDD.
- Durante lo sviluppo si scrivono tutti i test che, una volta consegnata l'applicazione fungeranno da test di regressione. Ogni aggiunta o modifica futura all'applicazione potrà essere sviluppata senza il rischio di compromettere funzionalità già esistenti (sì, quei bug che appaiono su funzionalità che andavano a meraviglia quando aggiungiamo qualcosa di nuovo, si chiamano Regressioni). Questo vantaggio ovviamente si verifica anche nel caso di eventuali refactoring.
- Scrivere i test prima dello sviluppo aiuta nelle stime delle tempistiche. Con il TDD spesso la stima, che solitamente è una brutta gatta da pelare per ogni #Project Manager, diventa un problema elementare del tipo: La mamma va al mercato perchè deve comprare un'applicazione che incorpora 10 test; sapendo che per far funzionare 5 test mediamente il programmatore impiega 2 ore, quanto tempo occorre al programmatore per codificare l'applicazione per la mamma?
- Scrivere i test documenta l'applicazione e le scelte prese dietro ogni funzione testata. Un nuovo programmatore che dovesse prendere in mano l'applicazione, potrebbe leggere i test e capire la logica come se stesse leggendo un documento di progetto.
Questi sono solo alcuni dei numerosi vantaggi derivanti dall'uso del TDD. E l'altro lato della medaglia? Parliamo degli svantaggi del TDD:
- Prima di sviluppare una funzionalità bisogna scriverne il codice di test e questo può rallentare lo sviluppo. Di fatto si scrive più codice rispetto all'applicazione senza test.
- Il TDD richiede di essere utilizzato da tutto il Team. Non è auspicabile sviluppare un'applicazione in cui metà team usa TDD mentre l'altra metà non lo usa. L'architettura e la logica dell'applicazione risulterebbero incongruenti. Gli accoppiamenti inevitabilmente introdotti da chi non usa TDD finirebbero per ostacolare chi invece lo usa.
- I Test devono essere mantenuti al pari del codice. Ogni refactoring comporta la modifica del codice applicativo e di tutti i test relativi.
Il TDD è una metodologia di sviluppo collegata ad Extreme Programming, che fa parte delle discipline Agile
Il #TDD richiede la ripetizione di un piccolo ciclo, appunto ciclo TDD, che si basa su 3 fasi:
1) Fase rossa: si scrive un test per una funzionalità del #software e, siccome la funzionalità non è ancora stata implementata, il test ovviamente fallisce
2) Fase verde: si scrive il codice applicativo necessario a far passare il test
3) Refactoring: si esegue refactoring sul codice scritto nella fase verde. E' in questa fase che si cerca di ottimizzare il codice.
Il TDD ci chiede di sviluppare il codice partendo già dal risultato che si vuole ottenere. Questa metodologia di codifica, benchè alle prime esperienze possa sembrare disorientante, di fatto comporta enormi vantaggi a più livelli:
- Visto che prima di ogni porzione di codice applicativo si scrive il relativo Test, teoricamente l'applicazione è completamente testata, quindi il Code Coverage applicativo è molto alto. Questo è un vantaggio per l'applicazione stessa quindi per il cliente in primis, che avrà un prodotto di qualità tendenzialmente bug free.
- Il tempo speso a fare #Debug si riduce enormemente perchè di fatto la maggior parte del Debug lo faranno i test per noi. Questo è un vantaggio per lo sviluppatore perchè può ottimizzare il proprio tempo ed evitare di spendere giornate per trovare quel fastidiosissimo bug.
- Scrivere e testare una funzionalità per volta spinge il programmatore a separare bene le varie responsabilità e ad aderire al Single Responsibility Principle (principio di singola responsabilità) per cui ogni classe, metodo e variabile deve avere una ed una sola responsabilità. L'applicazione finale sarà semplicemente migliore.
- Similarmente al punto precedente, il TDD spinge verso il Loose Coupling(accoppiamento debole), per cui ogni classe non dipende dalle altre ma è anzi indipendente e permette di essere sostituita agilmente senza danneggiare l'intero sistema. Progettare e sviluppare in TDD ci spinge prepotentemente verso una architettura modulare, con #IOC e #Dependency Injection ed un sistema estremamente disaccoppiato. Questo aspetto, è quello che giudico personalmente il più grande vantaggio del TDD.
- Durante lo sviluppo si scrivono tutti i test che, una volta consegnata l'applicazione fungeranno da test di regressione. Ogni aggiunta o modifica futura all'applicazione potrà essere sviluppata senza il rischio di compromettere funzionalità già esistenti (sì, quei bug che appaiono su funzionalità che andavano a meraviglia quando aggiungiamo qualcosa di nuovo, si chiamano Regressioni). Questo vantaggio ovviamente si verifica anche nel caso di eventuali refactoring.
- Scrivere i test prima dello sviluppo aiuta nelle stime delle tempistiche. Con il TDD spesso la stima, che solitamente è una brutta gatta da pelare per ogni #Project Manager, diventa un problema elementare del tipo: La mamma va al mercato perchè deve comprare un'applicazione che incorpora 10 test; sapendo che per far funzionare 5 test mediamente il programmatore impiega 2 ore, quanto tempo occorre al programmatore per codificare l'applicazione per la mamma?
- Scrivere i test documenta l'applicazione e le scelte prese dietro ogni funzione testata. Un nuovo programmatore che dovesse prendere in mano l'applicazione, potrebbe leggere i test e capire la logica come se stesse leggendo un documento di progetto.
Questi sono solo alcuni dei numerosi vantaggi derivanti dall'uso del TDD. E l'altro lato della medaglia? Parliamo degli svantaggi del TDD:
- Prima di sviluppare una funzionalità bisogna scriverne il codice di test e questo può rallentare lo sviluppo. Di fatto si scrive più codice rispetto all'applicazione senza test.
- Il TDD richiede di essere utilizzato da tutto il Team. Non è auspicabile sviluppare un'applicazione in cui metà team usa TDD mentre l'altra metà non lo usa. L'architettura e la logica dell'applicazione risulterebbero incongruenti. Gli accoppiamenti inevitabilmente introdotti da chi non usa TDD finirebbero per ostacolare chi invece lo usa.
- I Test devono essere mantenuti al pari del codice. Ogni refactoring comporta la modifica del codice applicativo e di tutti i test relativi.