Cos'è il test-driven development (TDD)

Di solito si pensa che prima si scrive il codice e poi, se rimane tempo, si scrivono i test. Il test-driven development ribalta questa logica: prima il test, poi il codice che lo fa passare. Sembra controintuitivo, ma è una pratica che cambia il modo di progettare il software.

In questo articolo ti spiego cos'è il TDD, com'è fatto il suo ciclo e quando conviene davvero adottarlo.

Cos'è il TDD in parole semplici

Il test-driven development (TDD) è una pratica di sviluppo in cui scrivi prima un test che fallisce, poi il codice minimo per farlo passare, e infine migliori il codice mantenendo il test verde. In pratica, il test guida la scrittura del codice (da qui "test-driven", guidato dai test).

L'idea di fondo è semplice: se sai descrivere con un test cosa deve fare il codice prima di scriverlo, hai già chiarito il problema. Il codice diventa una conseguenza di un requisito ben definito, non un tentativo al buio.

Il ciclo red-green-refactor

Il cuore del TDD è un ciclo di tre fasi che si ripete di continuo:

Red (rosso): scrivi un test per una funzionalità che ancora non esiste. Il test fallisce, perché il codice non c'è. È normale e voluto.
Green (verde): scrivi il codice minimo necessario per far passare il test. Niente di più: l'obiettivo è solo far diventare verde la barra.
Refactor (rifattorizza): ora che hai la rete di sicurezza del test verde, migliori il codice — nomi, struttura, duplicazioni — senza cambiarne il comportamento.

Poi si riparte dal red con la funzionalità successiva. A piccoli passi, costruisci un software coperto da test fin dal primo minuto.

# 1. RED: scrivo il test prima
def test_iva():
    assert con_iva(100) == 122

# 2. GREEN: codice minimo per passare
def con_iva(prezzo):
    return prezzo * 1.22

# 3. REFACTOR: miglioro senza rompere il test
ALIQUOTA_IVA = 1.22
def con_iva(prezzo):
    return prezzo * ALIQUOTA_IVA

I vantaggi del TDD

Design migliore: pensare prima al test ti costringe a progettare interfacce chiare e funzioni piccole.
Copertura garantita: ogni riga di codice nasce per soddisfare un test, quindi la suite cresce in modo naturale.
Meno paura di cambiare: il refactoring diventa sicuro perché i test ti avvisano subito se rompi qualcosa.
Feedback rapido: scopri gli errori in pochi secondi, non dopo ore di debugging.

Quando conviene (e quando no)

Il TDD brilla quando la logica è complessa o critica, quando i requisiti sono abbastanza chiari e quando il codice dovrà vivere a lungo. È meno adatto per prototipi usa-e-getta o quando stai ancora esplorando un'idea e l'interfaccia cambia di continuo.

Non è una religione: molti sviluppatori lo usano in modo selettivo, applicandolo alle parti che ne traggono più valore.

Un consiglio onesto per chi inizia

Se stai imparando a programmare da zero, il TDD può sembrare un peso in più. Va bene così: prima impara a scrivere dei semplici test dopo il codice, poi prova a invertire l'ordine su un piccolo esercizio. Sentire il ciclo red-green-refactor "sulle dita" è il modo migliore per capirne il valore.

In sintesi

Il TDD è una pratica in cui scrivi il test prima del codice, seguendo il ciclo red-green-refactor: test che fallisce, codice minimo per farlo passare, refactoring in sicurezza. Porta a un design più pulito e a una copertura di test naturale, ma va applicato con buon senso, soprattutto dove la logica è importante.

Vuoi imparare a sviluppare guidato dai test, con esempi pratici e revisioni? Lo trovi nei corsi di CodeGrind.