Definizione breve

Test Driven Development — disciplina di sviluppo in cui il test che descrive il comportamento atteso viene scritto prima del codice che lo implementa.

Definizione dettagliata

Nel senso tecnico consolidato, il TDD indica un ciclo breve e ripetuto: scrivere un test che fallisce, scrivere il codice minimo che lo fa passare, rifattorizzare il codice senza rompere il test. È una pratica di progettazione del codice quanto una pratica di test.

Negli articoli di questo blog, il termine è usato da un'angolazione più ristretta: il test che precede il codice viene considerato un artefatto di specifica. Esprime il cosa — il comportamento atteso, ciò che deve restare vero — mentre il codice esprime il come. Per questo interessa il prodotto quanto lo sviluppo: fissa un accordo su un comportamento in una forma che la macchina valuta, e che quindi non può divergere in silenzio dall'implementazione.

Uso nel dominio

Discussioni sulla riduzione del numero di difetti prodotti, definizione di una politica della qualità, decisioni sul costo dei test, formalizzazione dei criteri di accettazione di una funzionalità.

Sinonimi e varianti

Test Driven Development · sviluppo guidato dai test · test-first.

Da non confondere con

• Test automatizzati — test eseguiti da una macchina, senza indicazioni sul momento in cui sono stati scritti; scritti dopo il codice, constatano ciò che fa.
• BDD (Behaviour Driven Development) — formulazione dei comportamenti attesi in un linguaggio leggibile anche da chi non sviluppa, orientata al dialogo con gli esperti di dominio.
• Test di non regressione — insieme di test rieseguito per verificare che un comportamento esistente non sia stato rotto, indipendentemente dal fatto che sia stato scritto prima del codice.
• QA — funzione che definisce e verifica i criteri di qualità; il TDD è una pratica degli sviluppatori stessi.

Esempi

«Il test descrive il cosa. Il codice implementa il come.»

Un comportamento atteso fissato da un test prima dell'implementazione resta verificabile dopo diversi refactoring del codice, mentre la prosa che lo descriveva ha smesso da tempo di essere riletta.

Ambiguità / dibattiti

La sigla viene spesso usata per indicare qualunque pratica di test automatizzato, il che cancella l'unica cosa che la caratterizza: il fatto che il test venga prima del codice.

Il suo valore resta discusso — pratica di progettazione per alcuni, costo di scrittura aggiuntivo per altri —, e il dibattito raramente verte sulla stessa cosa, a seconda che si parli del ciclo completo o del solo test-first.