Idea principale

Scrivere prima il test e poi il codice inverte l'ordine abituale, ma l'interesse non sta nell'ordine. Il test descrive il cosa — ecco il comportamento atteso, ecco ciò che deve restare vero. Il codice descrive il come. Il primo è quindi un pezzo della specifica, scritto in un linguaggio che la macchina sa valutare.

Ciò che cambia si vede nel tempo. Il codice verrà rifattorizzato, incontrerà nuovi dati, altre funzionalità gli cresceranno intorno. Il comportamento atteso, invece, è fissato in un luogo diverso dalla memoria di chi l'ha implementato: se si rompe, il test fallisce, idealmente sulla macchina dello sviluppatore o in ambiente di test invece che in produzione.

Il TDD non elimina i difetti, non sostituisce la riflessione di prodotto e non trasforma una cattiva specifica in un buon prodotto. Fa una cosa sola, ed è una cosa rara: rende verificabile una parte della qualità prima che il codice esista.

Perché è importante

Fa uscire la disciplina dal registro dell'igiene tecnica. Un test scritto prima è un artefatto di specifica, quindi un luogo in cui prodotto e sviluppo possono accordarsi su un comportamento — cosa che un documento in prosa non consente, perché non si può valutare.

Sposta anche il senso dei test: scritti dopo, constatano ciò che il codice fa; scritti prima, vincolano ciò che dovrà fare.

Sfumature e limiti

La parte formalizzabile è ristretta. Un test dice che un comportamento è rispettato, mai che fosse il comportamento giusto da perseguire — la porzione di qualità che dipende dal giudizio di prodotto resta tutta da coprire.

E la disciplina presuppone di saper enunciare il comportamento atteso. Davanti a una specifica troppo vaga, scrivere prima il test non chiarisce nulla: congela l'ambiguità invece di scioglierla.

Domande aperte

• Quale artefatto può svolgere, per la parte del comportamento atteso che non si esprime in un test, il ruolo che il test svolge per quella che vi si esprime?