Cos'è lo sviluppo basato su test (TDD)?

Gli sviluppatori scrivono il codice sufficiente per superare ogni test, quindi sia il test che il codice vengono perfezionati prima di passare a un nuovo test e poi a una nuova funzionalità.

Lo sviluppo basato su test costringe essenzialmente gli sviluppatori a rallentare, convalidare e perfezionare il codice in cicli di feedback più brevi. Sebbene non sia necessario, i team DevOps incoraggiano i programmatori, dai principianti ai professionisti esperti, a utilizzare la metodologia TDD in un'ampia gamma di linguaggi di programmazione. Ad esempio, Java, Python e molti altri, application programming interface (API) e applicazioni di programma.

La programmazione in questo stile rafforza la relazione tra codifica, test (sotto forma di test automatici a livello di unità) e progettazione del codice. Sebbene lo sviluppo basato su test possa aumentare i tempi di sviluppo iniziali, è stato dimostrato che migliora la funzionalità e la destrezza del codice e consente di risparmiare tempo in generale.

Identificando e risolvendo immediatamente eventuali errori, gli sviluppatori che utilizzano TDD possono evitare che piccoli problemi diventino problemi più grandi. Lo sviluppo basato su test obbliga gli sviluppatori a convalidare e perfezionare il codice via via che procedono, semplificando così i controlli e le correzioni finali di qualità. 

I framework di test alternativi includono la scrittura del codice di produzione prima di scrivere tutti i test automatici o la scrittura dell'intera suite di test prima di scrivere il codice di produzione. Questi metodi, sebbene non necessariamente inefficaci, hanno dimostrato di aumentare i tempi di debug necessari, soprattutto con progetti più grandi e complessi.

Sebbene lo sviluppo basato su test sia comunemente utilizzato per la creazione di nuovo codice di produzione, viene spesso applicato anche per migliorare il debug del codice legacy sviluppato con tecniche precedenti o di altro tipo. 

Lo sviluppo basato su test inverte il processo di sviluppo tradizionale anteponendo i test allo sviluppo. Come approccio iterativo, lo sviluppo basato su test migliora la qualità e la leggibilità del codice promuovendo workflow testabili che producono codice di alta qualità a livello di unità. Quando gli sviluppatori implementano i test unitari, si concentrano su una piccola parte della logica, come un algoritmo individuale. Scrivere codice specificamente per far superare i test non solo si traduce in un codice più pulito e duraturo, ma aiuta anche a migliorare la documentazione. 

Esistono due livelli principali di sviluppo basato su test.

Per l'acceptance TDD, a volte chiamato Behavior-Driven Development (BDD), i programmatori scrivono un singolo test di accettazione e poi abbastanza nuovo codice per poterlo superare. I test di accettazione sono talvolta chiamati test del cliente o test di accettazione del cliente.

In genere possono essere intesi come casi di prova richiesti per la funzionalità minima, come delineato dagli stakeholder del prodotto. L'ATDD cerca di identificare requisiti dettagliati ed eseguibili. I test di accettazione possono essere eseguiti utilizzando vari strumenti di test, come Fitnesse o RSpec.

A volte chiamato semplicemente TDD, il developer TDD richiede ai programmatori di scrivere singoli test per valutare la propria soluzione a un test ATDD. Il developer TDD utilizza strumenti di automazione dei test, come JUnit o VBUnit. 

Quando si utilizza una strategia di sviluppo basata su test, i programmatori scrivono prima dei test per controllare ogni singolo elemento o funzione di un software, quindi scrivono codice sufficiente per superare quel singolo test. Una volta completato, il software viene nuovamente testato e, se il test viene superato, il codice viene perfezionato (un processo noto come refactoring) per includere solo elementi essenziali. Gli sviluppatori ripetono poi questo processo per ogni successiva funzione software. 

Il processo di sviluppo basato su test è suddiviso in cinque fasi individuali:

1. Prima di scrivere il codice per una determinata funzione software, gli sviluppatori scrivono innanzitutto un test unitario individuale per quella funzione.
2. Gli sviluppatori eseguono quindi il test, che dovrebbe fallire perché la funzione del codice non è ancora stata scritta. Questo passaggio è importante per confermare che il test stesso sia funzionale e non restituisca falsi positivi. Se il codice passa il test, significa che il test deve essere riscritto.
3. Quando il programma non supera il test, gli sviluppatori scrivono solo una quantità sufficiente di codice software aggiuntivo per superare il test. 
4. Quando il codice è in grado di superare il test, sia il test che il codice vengono rifattorizzati ai fini della semplicità e per eliminare il codice non necessario. 
5. Quando il software sufficientemente rifattorizzato è in grado di superare il test di rifattorizzazione, gli sviluppatori passano alla funzione software successiva desiderata. I tester scrivono ed eseguono quindi test per ogni nuova funzionalità. 

In parole semplici, il processo di sviluppo basato su test segue un ciclo ripetibile, denominato ciclo di refactoring rosso-verde. Le fasi del ciclo sono:

• Rosso: scrivere un test fallito per il comportamento previsto del software. 

• Verde: scrivere abbastanza extra per superare il test.

• Refactoring: riformulare il codice per soddisfare il più possibile gli standard di semplicità, pur continuando a superare il test.

Sebbene le origini specifiche dello sviluppo basato su test siano sconosciute, il concetto di scrivere prima i test e poi il codice di produzione non è stato una pratica comune fino alla metà degli anni '90. Prima di allora, i framework di test separavano gli sviluppatori dai test delle proprie basi di codice. Tuttavia, con l'evoluzione dell'ingegneria del software, i team DevOps hanno richiesto metodologie più rapide e flessibili per soddisfare le richieste degli stakeholder, soprattutto quando si tratta di requisiti in rapida evoluzione. 

Lo sviluppo basato su test si è evoluto da e insieme a vari nuovi framework di test ed è stato adottato anche come componente modulare in vari altri framework. In particolare, TDD è incluso nel concetto di Extreme Programming (XP), un framework di sviluppo software Agile sviluppato per migliorare sia la qualità del software che la qualità della vita degli sviluppatori.

Kent Beck, software engineer e figura di spicco della comunità Agile, nonché creatore di Extreme Programming, va il merito di avere "riscoperto" lo sviluppo basato su test. Nelle parole di Beck: 

"La descrizione originale del TDD era contenuta in un vecchio libro sulla programmazione. Diceva che bisogna prendere il nastro di input, digitare manualmente il nastro di output previsto, quindi programmare finché il nastro di output effettivo non corrisponde all'output previsto. Dopo avere scritto il primo framework xUnit in Smalltalk, mi sono ricordato di averlo letto e di averlo provato. Per me è stata questa l'origine del TDD. Quando descrivo il TDD ai programmatori più anziani, sento spesso dire: " Certo. In quale altro modo potresti programmare?" Per questo motivo, definisco il mio ruolo come "riscoperta" del TDD." 

Tra le date importanti nell'evoluzione dello sviluppo basato su test ci sono:

• 1976: Glenford Myers pubblica Software Reliability, in cui sostiene che "uno sviluppatore non dovrebbe mai testare il proprio codice". Anche se Myers potrebbe non essere stato l'ideatore di questo concetto, il suo lavoro ha dato credito a un'idea comune che si sarebbe diffusa negli anni a venire. 

• 1990: all'inizio del decennio, la tecnica della "black box" dominava i test del software. In questo tipo di framework, i tester trattano il software come se fosse una "black box", impenetrabile e impossibile da conoscere. Nei test black-box vengono impiegati tester che, di fatto, non hanno alcuna conoscenza del funzionamento interno del software. 

• 1994: Kent Beck sviluppa SUnit, un framework per Smalltalk, gettando le basi per un approccio test-first per l'ottimizzazione della base di codice. 

• 1999—2002: via via che il movimento per lo sviluppo Agile prende piede, Kent Beck sviluppa il concetto di Extreme Programming, codificando lo sviluppo basato su test e introducendo il concetto critico degli oggetti fittizi. Il TDD utilizza oggetti fittizi per simulare i comportamenti delle dipendenze reali (ad esempio, database, servizi esterni e così via) durante i test. Questo metodo aiuta gli sviluppatori a concentrare il proprio codice di test su oggetti fittizi gestibili, il cui funzionamento accurato può essere verificato. Un test che fallisce e che utilizza un oggetto fittizio può eliminare una dipendenza potenzialmente mal configurata come fonte del fallimento. 

• 2003: Kent Beck pubblica Test Driven Development: By Example, diffondendo la pratica tra nella più ampia community di sviluppo e legittimando ulteriormente i test guidati dagli sviluppatori. 

Come componente di Extreme Programming, lo sviluppo basato su test è risultato utile non solo per creare codice migliore, ma anche per rendere migliori i programmatori. Il TDD consente ai programmatori di ottenere insight migliori sui loro progetti e di contribuire alla progettazione dei programmi. Mettendo al centro il test case prima dell'implementazione di ogni funzionalità, gli sviluppatori devono visualizzare come una funzione verrà utilizzata da un cliente o da un utente. Questo approccio posiziona l'interfaccia del prodotto prima dell'implementazione e aiuta gli sviluppatori a creare applicazioni più orientate all'utente. 

Alcuni benefici aggiuntivi dello sviluppo basato su test includono:

• Copertura completa dei test: il TDD viene talvolta definito uno strumento di specifica o documentazione perché la pratica garantisce che tutto il codice sia coperto da almeno un test. 

• Documentazione migliorata: per lo stesso motivo per cui il TDD offre una copertura completa, fornisce anche documentazione e specifiche solide. Questo sistema aiuta gli sviluppatori, i project manager e gli stakeholder a convalidare le feature e i requisiti del codice e a stabilire l'ordine durante il ciclo di vita del progetto. 

• Maggiore fiducia: gli sviluppatori e i team DevOps che utilizzano il TDD acquisiscono maggiore fiducia non solo nel loro codice ma anche nei test. 

• Facilita l'integrazione continua: il TDD è adatto per le pratiche di integrazione continua, in cui il codice live viene continuamente aggiornato con nuove caratteristiche e patch. 

• Debugging ridotto: il TDD anticipa i test nel processo di sviluppo, riducendo la necessità di un debug esteso alla fine dello sviluppo. 

• Maggiore chiarezza dei requisiti: il TDD aiuta gli sviluppatori a stabilire una chiara comprensione di ogni requisito specifico del programma prima di iniziare a lavorare. 

• Produttività migliorata: il TDD è spesso collegato a una maggiore produttività tra gli sviluppatori poiché il processo aiuta ad atomizzare progetti di grandi dimensioni in fasi più piccole e più realizzabili. 

• Rafforza il design semplice: la terza fase critica del ciclo TDD di refactoring verde-rosso richiede agli sviluppatori di rifattorizzare e semplificare il codice. Questa pratica migliora la semplicità generale e la qualità della progettazione. 

• Rafforza i modelli mentali: esaminando e integrando ogni funzione o requisito unico, il TDD aiuta i programmatori a sviluppare un modello mentale forte del codice in questione. Questo modello mentale aiuta gli sviluppatori a visualizzare le funzioni e i requisiti generali del codice mentre ci lavorano. 

• Stabilità del sistema migliorata: è stato dimostrato che l'uso dello sviluppo basato su test migliora la stabilità complessiva dell'applicazione creando codice robusto e ben testato, in linea con elevati standard di semplicità nella progettazione. 

Sebbene l'utilizzo dello sviluppo basato su test (TDD) offra molti benefici preziosi, non è privo di problematiche. Sebbene la gravità di queste problematiche possa dipendere dal progetto o essere mitigata con varie altre tecniche, alcuni degli svantaggi del TDD includono:

• Maggiore volume di codice: il TDD richiede ai programmatori non solo di scrivere codice per ogni funzionalità richiesta, ma anche di testare ogni funzionalità. L'aggiunta del codice di test con il codice del prodotto comporta una base di codice complessiva più ampia. 

• Falsa fiducia: poiché ogni caratteristica è scritta per superare un test, programmatori e project manager possono sviluppare un falso senso di sicurezza nella funzionalità complessiva del codice. Anche se ogni caratteristica integrata è testata, il TDD non sostituisce la necessità del controllo di qualità finale e dei test API. 

• Aumento dell'overhead: il TDD richiede ai codificatori di mantenere un'ampia suite di test oltre al codice di produzione. La manutenzione dei codebase di test richiede una certa quantità di risorse e può aumentare i costi generali. 

• Riduzione dell'efficienza: sebbene sia stato dimostrato che il TDD migliora la produttività, può ritardare lo sviluppo del progetto, poiché aggiunge ulteriori passaggi alla creazione e all'implementazione di ogni nuova funzionalità. 

• Aumento del tempo di preparazione: il TDD richiede agli sviluppatori di creare e mantenere ambienti di test adeguati per il loro codice. 

• Perdita di vista del design complessivo: sebbene il TDD incoraggi la semplicità del codice e il miglioramento della progettazione, concentrarsi troppo sui singoli componenti può portare a un codice meno armonioso nel suo complesso. I programmatori che utilizzano il TDD devono sapere come gli aggiornamenti delle loro singole funzionalità si integreranno quando saranno compilati nell'applicazione.