Test-Driven Development

Il Test-Driven Development è semplice da descrivere e difficile da padroneggiare:

1. Rosso: Scrivi un test che fallisce per il prossimo piccolo pezzo di funzionalità
2. Verde: Scrivi il codice minimo per far passare il test
3. Refactoring: Pulisci il codice mantenendo i test verdi

Tutto qui. Tre passaggi, ripetuti centinaia di volte al giorno.

L'ordine è importante. Scrivi il test per primo, prima che esista qualsiasi codice di produzione. All'inizio sembra controintuitivo. Ma cambia tutto:

• Pensi a come verrà usato il codice prima di come verrà implementato
• Ottieni feedback immediato sul fatto che il tuo codice funzioni
• Costruisci una rete di sicurezza che abilita cambiamenti senza paura
• Crei documentazione eseguibile di ciò che fa il codice

La parte più difficile del TDD è imparare a scrivere test per codice che non esiste ancora. Ecco come:

Inizia dall'interfaccia, non dall'implementazione. Come dovrebbe apparire il codice quando è finito? Scrivi un test che lo usi in quel modo.

Inizia in piccolo. Non cercare di testare tutto in una volta. Testa prima il caso più semplice possibile.

Fallo fallire per il motivo giusto. Il test dovrebbe fallire perché la funzionalità non esiste, non perché hai fatto un errore di sintassi.

Usa i nomi dei test come documentazione. Il nome del test dovrebbe descrivere quale comportamento stai testando: "restituisce lista vuota quando nessun elemento corrisponde al filtro" non "test1."

Scrivere prima il test ti costringe a pensare a:

• Quali input necessita questo codice?
• Quali output dovrebbe produrre?
• Cosa succede nei casi limite?
• Come chiamerà questo codice altro codice?

Queste sono domande di design. Rispondendo prima di scrivere il codice, prendi decisioni di design migliori.

Una volta che hai un test che fallisce, fallo passare. Ma ecco la disciplina: scrivi il codice minimo per far passare il test, niente di più.

Questo significa:

• Se una costante fa passare il test, usa una costante
• Se hard-codare un valore di ritorno funziona, hard-codalo
• Non generalizzare finché non hai test che richiedono generalizzazione

Sembra ridicolo. "Restituire semplicemente 5?" Sì, se questo fa passare il test. Poi scrivi un altro test che ti costringe a fare un calcolo reale.

Perché? Perché:

• Costruisci funzionalità in piccoli passi verificati
• Non scrivi mai codice di cui non hai bisogno
• Scopri il design in modo incrementale
• Ogni riga di codice è giustificata da un test

La magia avviene quando triangoli. Primo test: restituisci 5. Secondo test (input diverso): ora devi calcolare. Terzo test: ora devi gestire i casi limite. Ogni test ti spinge verso un'implementazione reale.

Dopo che il test passa, pulisci. Questo non è opzionale.

Il passaggio di refactoring è dove:

• Rimuovi la duplicazione (DRY: Don't Repeat Yourself)
• Migliori i nomi (fai leggere il codice come prosa)
• Semplifichi la logica (riduci il carico cognitivo)
• Riorganizzi (sposta il codice dove appartiene)

La chiave: mantieni i test che passano per tutto il tempo. Effettua il refactoring in piccoli passi, eseguendo i test dopo ogni cambiamento. Se i test falliscono, sai esattamente cosa si è rotto.

È qui che il TDD ripaga. Senza test, il refactoring è terrificante—potresti rompere qualcosa. Con i test, il refactoring è routine—saprai immediatamente se rompi qualcosa.

Saltare il passaggio di refactoring porta a quello che Kent Beck chiama "scuse verdi veloci." Il codice funziona, ma è disordinato. Il disordine si accumula. Presto la codebase è difficile da gestire, e hai perso il beneficio del TDD.

Mito: Il TDD è più lento. Realtà: Il TDD sembra più lento all'inizio perché scrivi più codice. Ma passi meno tempo a fare debug, meno tempo nel debugger, meno tempo a correggere bug in produzione. Nel corso della vita della codebase, il TDD è più veloce.

Mito: Il TDD porta a over-testing. Realtà: Il TDD porta esattamente ai test di cui hai bisogno—né più, né meno. Testi ciò che costruisci. Il test-after spesso porta a test mancanti (dimentichi i casi limite) o test ridondanti (testi la stessa cosa in modi diversi).

Mito: Il TDD non funziona per [il mio dominio]. Realtà: Il TDD funziona per qualsiasi codice che può essere testato. Se il tuo codice non può essere testato, è un problema di design. Il TDD ti costringe a scrivere codice testabile, che è codice migliore.

Mito: Non abbiamo tempo per il TDD. Realtà: Non hai tempo per non farlo. I bug sono costosi. Il debugging è costoso. Gli incidenti in produzione sono costosi. Il TDD è un investimento che ripaga.