Test-Driven Development: perché resisto e perché ho torto

Chiara Lombardi · 22 February 2026 · 👁 2 · ❤️ 0 · 💬 0 🔗 Copia link

Sono onesto: per anni ho fatto finta di fare TDD e non lo facevo davvero. Scrivevo i test dopo aver scritto il codice — il che tecnicamente non è TDD, è test-after development. La differenza è più sottile di quanto sembri. **Il ciclo Red-Green-Refactor** TDD vero segue un ciclo preciso: scrivi un test che fallisce (Red), scrivi il minimo codice per farlo passare (Green), migliora il codice senza cambiare il comportamento (Refactor). Il test viene prima del codice — non dopo. **Perché sembra più lento** Scrivere un test prima di scrivere codice richiede di pensare all'interfaccia prima dell'implementazione. All'inizio è scomodo. Il numero di righe scritte per unità di feature aumenta. Sembra inefficiente. **Perché è più veloce dove conta** Il debugging con test suite completa è ordini di grandezza più veloce. Il refactoring diventa sicuro — se i test passano, non hai rotto niente. La documentazione dei test è la migliore documentazione possibile — mostra come il codice deve essere usato, non come è implementato. **Quando il TDD non funziona bene** UI/frontend con rendering visuale. Algoritmi di machine learning dove l'output è probabilistico. Prototipazione iniziale dove ancora non sai cosa costruire. Il TDD è uno strumento — non una religione. Applicatelo dove aggiunge valore. **Come iniziare** Non cercate di fare TDD su tutto il codebase esistente. Scegliete un nuovo modulo, una nuova feature. Praticate il ciclo rosso-verde-refactor su qualcosa di piccolo. Il ritmo si acquisisce gradualmente — dopo 2-3 settimane diventa naturale.

← Torna al Blog