TDD is dead. Long live testing. (Une contre-argumentation point à point à l'article phare de David Heinemeier Hansson, détracteur du Test-driven development)

Punti chiave

1. Data / fonte. 7 dicembre 2022 (iniziale), 17 marzo 2025 (ultimo aggiornamento). Blog personale mathieueveillard.com. Categorie: craft, best-of.
2. Autore. Mathieu Eveillard — sviluppatore / craft coach / formatore.
3. Bersaglio. DHH, "TDD is dead. Long live testing." (RailsConf 2014, post su Signal v Noise).
4. Tesi cruciale. il TDD non è una religione, è uno strumento. E DHH in realtà critica il Test-first, non il TDD. ### La distinzione cruciale di Eveillard | Concetto | Definizione | |---------|-----------| | Test-first | Scrivo tutti i test prima di scrivere una sola riga di codice | | Test-Driven Development | I test mi guidano nella scrittura del codice — ogni volta scrivo un po' di codice in reazione a un nuovo test | > "È un peccato che questa confusione non venga mai chiarita, perché nasconde un modo di programmare completamente diverso." ### Le 3 confutazioni punto per punto #### (1) "Il TDD come martello per abbattere i non credenti" DHH: il TDD usato come martello per puntare il dito contro i non credenti, per dichiararli non professionali. Eveillard concede: non ha senso puntare il dito, in contrasto con l'umiltà dell'artigiano. Ma ridefinisce il "buon codice":
5. Al di là dell'assenza di bug;
6. Unit test. che documentano il comportamento al livello più basso;
7. Collocati insieme. al codice;
8. Rete di sicurezza. — "Più la maglia è fine, meglio si evitano le regressioni". #### (2) "Riequilibrare lo spettro dei test dallo unit al system" DHH: spostamento dagli unit test (con mock) ai test di sistema. Eveillard risponde:
9. Il TDD non vieta nulla al di là degli unit test.
10. I test di sistema non sostituiscono gli unit test (una dichiarazione dei redditi testata end-to-end = assurdo).
11. Piramide dei test. — ogni tipo contribuisce con il proprio valore:
12. Unit test = feedback in millisecondi → guida la scrittura del codice tramite il TDD;
13. Individuazione precoce dei bug → costo inferiore. Sull'architettura: "mostruosità orrende (service object, command pattern)" — Eveillard non riscontra questi effetti nella programmazione funzionale, quindi è attribuibile all'OOP, non al TDD. #### (3) "Non scrivo software test-first" DHH: usa "Test first" pur annunciando il TDD nel titolo. Eveillard individua nella confusione semantica tra Test-first e TDD il difetto fondamentale dell'argomentazione di DHH. ### L'ambito ragionevole del TDD > "Il TDD è particolarmente adatto al codice di dominio, il nucleo funzionale di un bounded context. Il cuore dell'esagono, il cuore del reattore. Un motore di calcolo, regole di business a grana fine, casi limite ovunque. Lì, non so come fare altrimenti che con il TDD. Ma alla fine, questo rappresenta solo una piccola parte della codebase, al massimo il 30%." | Codice | TDD rilevante? | |------|----------------| | Dominio / regole di business / motore di calcolo | FORTEMENTE SÌ | | Codice di collegamento / orchestrazione / IO | Meno rilevante | | UI / boilerplate del framework | Non necessario | | Stima di Eveillard | Al massimo il 30% della codebase | ### Collegamento con il corpus di veille #### Rilevanza per il corpus IA / agenti di codifica 2025-2026 L'articolo è del 2022 (quindi prima dell'esplosione degli agenti di codifica) ma risuona con i dibattiti attuali:
14. Kent Beck — Vibe Coding vs TDD. (2024-10-17): Beck osserva che il vibe coding e il TDD non si escludono a vicenda — il TDD rimane rilevante per il codice di dominio, esattamente la posizione di Eveillard.
15. Beck — Augmented Coding Beyond Vibes. (2025-06-25): la posizione di "augmented coding" si basa su guardrail (test) che il TDD fornisce naturalmente.
16. Frizzo. Year With Claude Code (2026-05-05): "atrofia del muscolo della scrittura" — mantenere una pratica di TDD è proprio un antidoto all'atrofia della pratica manuale.
17. Osmani Cognitive Surrender. (2026-05-05): "PR ~100 righe max", tempo solitario alla tastiera — converge con l'idea di Eveillard secondo cui il TDD mantiene lo sviluppatore all'interno della pratica metodologica del mestiere.
18. Lattice. (2026-05-05): Atoms / Molecules / Refiners — granularità fine, esattamente ciò che il TDD incoraggia. #### Convergenza "strumento, non religione"
19. Eveillard. "Il TDD non è una religione, è uno strumento."
20. Karpathy. (2026-04-29): "jagged intelligence" — uno strumento con limiti di efficacia.
21. DORA ROI 2026. (2026-04-21): "tutti i modelli sono sbagliati ma utili" — umiltà metodologica.
22. Talisman Ontology Pipeline Refresh. (2026-05-04): "il lavoro non può essere saltato" — la metodologia come strumento disciplinare.
23. → Convergenza etica: rifiuto sia del dogmatismo SIA del rigetto di uno strumento metodologico. #### Convergenza sull'"ambito limitato"
24. Eveillard. TDD = al massimo il 30% della codebase (codice di dominio).
25. Stanford. (citato da DORA): produttività 35-40% greenfield vs ≤10% brownfield — distribuzione disomogenea in base al contesto.
26. Ng The Batch #350. (2026-04-24): Frontend > Backend > Infra > Research — accelerazione differenziata in base al contesto.
27. → Convergenza: nessuno strumento metodologico è universalmente applicabile — occorre sempre valutare l'ambito pertinente. ### Limiti da segnalare
28. Articolo esterno al corpus IA. in senso stretto — focus su craft / TDD storico. Rilevante indirettamente.
29. Nessun dato empirico. — argomentazione concettuale, non uno studio.
30. Nessun confronto con gli agenti di codifica. nella versione del 2025 (l'aggiornamento di marzo 2025 non sembra aver incorporato il dibattito su IA/agenti).
31. L'ambito del 30% è una stima non documentata da Eveillard — discutibile a seconda del contesto (un compilatore potrebbe essere all'80% dominio).
32. Impostazione fortemente orientata a FP/esagonale. — può apparire dogmatica agli sviluppatori fortemente radicati in OOP/Rails.
33. Non affronta. il dibattito sull'impatto del CI/CD sulla strategia di test che altri autori (in particolare DORA) considerano cruciale. ### Da utilizzare per
34. Sessioni di formazione interne craft / TDD. materiale didattico di riferimento in lingua francese.
35. Dibattiti di team sul TDD. argomentazione strutturata per chiarire Test-first vs TDD.
36. Collegamento con il corpus 2026 sugli agenti di codifica. collocare i dibattiti attuali (vibe coding, agenti, AI-augmented) nella continuità storica dei dibattiti craft.
37. Sourcing. l'aforisma "il TDD non è una religione, è uno strumento" — una formula sintetica utilizzabile.