Ciao, e benvenuto nella sesta puntata della sessantanovesima stagione. Finora abbiamo dato per scontata una cosa: prima scrivi il codice, poi lo testi. È l'ordine naturale, no? Prima costruisci, poi collaudi. Oggi ti propongo di ribaltarlo. C'è una pratica che dice: scrivi il test prima del codice. Si chiama sviluppo guidato dai test, e a prima vista suona assurdo. Come faccio a testare una cosa che non esiste ancora? Eppure, capito bene, cambia il modo stesso in cui pensi al codice.
Partiamo dal ritmo, perché è una danza in tre battute che si ripete. Prima battuta: scrivi un test per una funzionalità che ancora non hai costruito. Lo lanci, e ovviamente fallisce, diventa rosso: normale, il codice non c'è. Seconda battuta: scrivi il minimo indispensabile di codice per far diventare quel test verde. Non il codice bello, non il codice completo: solo quel che basta per passare. Terza battuta: ora che è verde, con la rete di sicurezza attiva, riordini e migliori il codice senza paura di romperlo. Rosso, verde, riordina. E poi da capo, per il pezzo successivo. Piccoli cicli, uno dietro l'altro, ciascuno di pochi minuti. Il codice cresce a piccoli morsi, ognuno subito verificato.
Vediamo la cosa che quasi nessuno dice sul serio, e che è il vero segreto di questa pratica. Lo sviluppo guidato dai test, in fondo, non parla di testing. Parla di progettazione. Pensaci: per scrivere il test prima del codice, sei costretto a rispondere a una domanda che di solito rimandi. Come voglio che si usi questa cosa? Che nome ha, cosa riceve, cosa restituisce? Stai progettando l'interfaccia prima di tuffarti nell'implementazione. Il test diventa il primo cliente del tuo codice: il primo pezzo di software che lo dovrà usare sei costretto a scriverlo tu, prima ancora che il codice esista. E un codice che nasce già usato, nasce più facile da usare: le interfacce contorte tendono a farsi notare subito, quando sei tu il primo a doverle chiamare.
Nota una conseguenza bellissima di questo ribaltamento. Quando scrivi il codice dopo il test, non ti perdi mai. Hai sempre un obiettivo piccolo e chiarissimo davanti: far diventare verde quel test lì. Niente pagine di codice scritte a intuito, sperando che alla fine tutto si incastri. Fai un passo, lo verifichi, fai il passo dopo. Ripensa alla scorsa stagione, ai piccoli passi dell'esecuzione: lo sviluppo guidato dai test porta quella stessa idea nel modo di lavorare. Avanzi per passettini controllati, e a ogni passo il terreno sotto di te è solido, perché appena verificato. Non c'è quel momento angosciante in cui scrivi cento righe e poi trattieni il fiato al primo avvio.
E qui devo essere onesto, perché questa pratica ha i suoi tifosi accaniti e non ho intenzione di venderti un dogma. Lo sviluppo guidato dai test brilla quando sai già cosa deve fare il codice, e la logica è ben definita: un calcolo, una regola di business, una trasformazione di dati. Lì è quasi magico. Ma è scomodo, a volte controproducente, quando stai esplorando, quando non sai ancora dove vuoi arrivare, quando stai facendo un prototipo per capire un'idea, o quando lavori su qualcosa di molto visivo, dove il giudizio è l'occhio e non un'asserzione. Costringersi a scrivere test prima, mentre brancoli nel buio, ti rallenta e basta. Lo strumento è ottimo, ma non per ogni lavoro.
C'è un fraintendimento da togliere di mezzo, perché blocca tante persone. Adottare questa pratica non è una scelta tutto o niente, per sempre. Non devi giurare che d'ora in poi scriverai ogni singola riga partendo da un test. Puoi usarla dove serve, e lasciarla dove intralcia. Magari la usi per il cuore logico di una funzionalità delicata, e non la usi per l'impalcatura intorno. È una marcia del cambio, non un interruttore. I bravi non sono quelli che la applicano sempre: sono quelli che sentono quando accende il pensiero e quando invece lo ingessa.
Ecco l'immagine che mi aiuta a ricordarne il senso. Scrivere il test prima è come scrivere la domanda dell'esame prima di studiare la risposta. Ti costringe a chiarire, fin dall'inizio, cosa conta davvero sapere, qual è il risultato che stai cercando. Troppo spesso, nel codice, partiamo a scrivere senza aver deciso cosa vogliamo ottenere di preciso, e ce ne accorgiamo solo alla fine, quando è tardi e costoso cambiare. Il test scritto prima ti obbliga a decidere la meta prima di metterti in cammino. E chi sa dove sta andando, ci arriva con meno giri a vuoto.
Per oggi ci fermiamo qui. Abbiamo ribaltato l'ordine: prima il test, poi il codice. Il ritmo è una danza in tre battute, rosso, verde, riordina: scrivi un test che fallisce, il minimo codice per farlo passare, poi migliori al sicuro. Il segreto vero è che questa pratica non parla di testing ma di progettazione: il test è il primo cliente del tuo codice, e ti costringe a decidere l'interfaccia prima dell'implementazione. Avanzi per piccoli passi verificati, come l'esecuzione della scorsa stagione. Ma non è un dogma: splende sulla logica ben definita, intralcia nell'esplorazione e nel lavoro visivo. Usala dove accende il pensiero, lasciala dove lo ingessa. Nella prossima puntata: oltre l'esempio. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.