# eveillard-tdd-is-dead-long-live-testing-reponse-dhh-2022-12-07

## Veille

**Mathieu Eveillard** pubblica sul suo blog personale il **7 dicembre 2022** (ultimo aggiornamento 17 marzo 2025) una **controargomentazione punto per punto** al celebre saggio di **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Articolo classificato **craft / best-of**, una posizione da **artigiano del software** che difende il **Test-Driven Development** senza dogmatismo. **Distinzione cruciale** che secondo Eveillard sfugge a DHH: ***"Test-first"*** (scrivere tutti i test prima di qualsiasi codice) vs ***"Test-Driven Development"*** (i test mi **guidano** nella scrittura del codice, per cui ogni volta scrivo un po' di codice *"in reazione"* a un nuovo test). DHH in realtà critica il *Test-first* chiamandolo TDD — una confusione che **nasconde un modo di programmare completamente diverso**. **Risposte punto per punto**: (1) *"TDD come martello per abbattere i non credenti"* — Eveillard concede il punto deontologico ma ridefinisce il *"buon codice"*: non solo l'assenza di bug ma **unit test a grana fine** che documentano il comportamento al livello più basso, collocati insieme al codice, una **rete di sicurezza**; (2) *"Riequilibrare dallo unit al system"* — il TDD **non dice nulla** sui test di sistema e **non afferma** che non esista nulla al di fuori del TDD; i test di sistema **non sostituiscono** gli unit test (una dichiarazione dei redditi testata end-to-end non ha senso); **piramide dei test** — ogni tipo contribuisce con la propria parte, gli unit test per un feedback in **millisecondi** + individuazione precoce dei bug; (3) *"Mostruosità architetturali orrende (service object, command pattern)"* — Eveillard risponde di **non riscontrare questi effetti nella programmazione funzionale**, quindi l'effetto è probabilmente dovuto all'**OOP**, non al TDD; ma concede che un'iniezione di dipendenze eccessiva può accoppiare test e implementazione. **Conclusione equilibrata**: *"Il TDD non è una religione, è uno strumento"*. Il TDD è particolarmente adatto al **codice di dominio** (il nucleo funzionale di un *bounded context*, il *cuore dell'esagono*) — motori di calcolo, regole di business a grana fine, casi limite ovunque — ***"al massimo il 30% della codebase"***. Cita la **Legge dello Strumento** (se lo strumento non aiuta, è perché ci si è caduti dentro). **Rilevanza per il corpus**: un **articolo di craft esterno al corpus IA** ma da archiviare per collocare gli attuali dibattiti sugli agenti di codifica (l'*Augmented Coding Beyond Vibes* di Beck, 2025-06-25, Vibe Coding vs TDD, l'*atrofia del muscolo della scrittura* di Frizzo) nella linea storica dei dibattiti craft sul TDD. Da utilizzare come **base di libreria** per sessioni di formazione.

## Titre Article

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

## Date

2022-12-07

## URL

https://www.mathieueveillard.com/blog/tdd-is-dead-long-live-testing

## Keywords

Mathieu Eveillard, TDD, Test-Driven Development, Controargomentazione a DHH, David Heinemeier Hansson, TDD is dead long live testing 2014, Distinzione tra Test-first e Test-Driven Development, unit test di basso livello, rete di sicurezza, piramide dei test, feedback in millisecondi, individuazione precoce dei bug, programmazione funzionale, iniezione di dipendenze, accoppiamento test-implementazione, codice di dominio, bounded context, cuore dell'esagono, martello per abbattere i non credenti, riequilibrare dallo unit al system, mostruosità architetturali orrende, service object command pattern, religione vs strumento, Legge dello Strumento, 30 percento della codebase, Glenn Gould pianista, craft, best-of, artigianato del software, blog di Mathieu Eveillard, 7 dicembre 2022, aggiornamento del 17 marzo 2025, collegamento con i dibattiti 2025-2026 sugli agenti di codifica, Kent Beck Augmented Coding Beyond Vibes

## Authors

**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD, du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).

## Ton

**Profilo**: Articolo di blog craft individuale, formato di saggio polemico misurato e lungo, tono da **artigiano del software umile ma fermo**. Pubblico target: sviluppatori intermedi/senior, tech lead, formatori craft, lettori di DHH/Rails curiosi dell'altro lato dell'argomentazione. Pubblico secondario: manager che cercano di capire i dibattiti interni di team sul TDD.

**Stile**: Voce in prima persona in francese, **registro colloquiale cortese** (*"Dubito che il signore si aspetti una risposta da parte mia"*), strutturato in **3 sezioni** corrispondenti alle 3 citazioni scelte di DHH. Nessun ad hominem: Eveillard riconosce DHH come *"un personaggio poliedrico"* (creatore di Ruby on Rails + vincitore delle 24 Ore di Le Mans), elogia le sue idee *"iconoclaste"*, ma confuta fermamente le conclusioni. **Argomentazione punto per punto** nella grande tradizione retorica. Metafore curate (Glenn Gould come pianista non accademico, il *cuore dell'esagono*, il *cuore del reattore*).

**Aforismi chiave**:
- ***"Il TDD non è una religione, è uno strumento."*** (la conclusione cruciale).
- ***"Tenete presente che potrei sbagliarmi, e che ciò che va bene per me non è necessariamente un bene per qualcun altro."*** (l'umiltà dell'artigiano).
- ***"Prima si individua un bug, meno costa."*** (la giustificazione economica del TDD).
- ***"Alla fine, questo rappresenta solo una piccola parte della codebase, al massimo il 30%."*** (l'ambito ragionevole del TDD).

**Metafore elaborate**:
- ***Rete di sicurezza*** — i test come una rete che protegge dalle regressioni.
- ***Piramide dei test*** — ogni tipo di test contribuisce con la propria parte alla struttura (riferimento a Mike Cohn).
- ***Cuore dell'esagono / cuore del reattore*** — riferimento all'**architettura esagonale** (Alistair Cockburn) — il nucleo funzionale di un bounded context.
- ***Glenn Gould, pianista non accademico*** — analogia artistica: un grande interprete può discostarsi dalle convenzioni accademiche pur producendo un risultato magistrale. Permette a Eveillard di concedere a DHH che **il risultato conta soprattutto**.
- ***Legge dello Strumento*** — se lo strumento non aiuta, è perché si è caduti nella trappola di Maslow (*"se tutto ciò che hai è un martello, tutto sembra un chiodo"*).

**Postura epistemica**: **equilibrata e autocritica**. Eveillard:
1. Concede dei punti a DHH (etica, nessun puntare il dito, il risultato conta).
2. **Chiarisce la confusione** tra Test-first e TDD.
3. Limita **l'ambito del TDD al 30% della codebase** (codice di dominio).
4. Rifiuta al contempo il **dogmatismo del TDD** e il **rigetto del TDD**.

**Autorevolezza**: costruita attraverso (a) **precisione tecnica** (distinzioni Test-first/TDD, esagonale, bounded context, FP), (b) **rigore retorico** — punto per punto, senza uomini di paglia, (c) **umiltà esplicita** (*"potrei sbagliarmi"*), (d) **riferimenti interni al blog** (DDD strategico vs tattico, incomprensione del DevOps) che mostrano un corpus coerente. Limite: **autorevolezza di un blog individuale** senza validazione istituzionale o empirica.

## Pense-betes

- **Data / fonte**: **7 dicembre 2022** (iniziale), **17 marzo 2025** (ultimo aggiornamento). Blog personale **mathieueveillard.com**. Categorie: `craft`, `best-of`.
- **Autore**: **Mathieu Eveillard** — sviluppatore / craft coach / formatore.
- **Bersaglio**: DHH, *"TDD is dead. Long live testing."* (RailsConf 2014, post su Signal v Noise).
- **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"**:
- Al di là dell'assenza di bug;
- **Unit test** che documentano il comportamento al livello più basso;
- **Collocati insieme** al codice;
- **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**:
- Il TDD **non vieta** nulla al di là degli unit test.
- I test di sistema **non sostituiscono** gli unit test (una dichiarazione dei redditi testata end-to-end = assurdo).
- **Piramide dei test** — ogni tipo contribuisce con il proprio valore:
- Unit test = feedback in **millisecondi** → guida la scrittura del codice tramite il TDD;
- 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:
- **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.
- **Beck — Augmented Coding Beyond Vibes** (2025-06-25): la posizione di *"augmented coding"* si basa su **guardrail** (test) che il TDD fornisce naturalmente.
- **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.
- **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**.
- **Lattice** (2026-05-05): Atoms / Molecules / Refiners — granularità fine, esattamente ciò che il TDD incoraggia. #### Convergenza "strumento, non religione"
- **Eveillard**: *"Il TDD non è una religione, è uno strumento."*
- **Karpathy** (2026-04-29): *"jagged intelligence"* — uno strumento con limiti di efficacia.
- **DORA ROI 2026** (2026-04-21): *"tutti i modelli sono sbagliati ma utili"* — umiltà metodologica.
- **Talisman Ontology Pipeline Refresh** (2026-05-04): *"il lavoro non può essere saltato"* — la metodologia come strumento disciplinare.
- → **Convergenza etica**: rifiuto sia del **dogmatismo** SIA del **rigetto** di uno strumento metodologico. #### Convergenza sull'"ambito limitato"
- **Eveillard**: TDD = al massimo il 30% della codebase (codice di dominio).
- **Stanford** (citato da DORA): produttività 35-40% greenfield vs ≤10% brownfield — **distribuzione disomogenea in base al contesto**.
- **Ng The Batch #350** (2026-04-24): Frontend > Backend > Infra > Research — **accelerazione differenziata in base al contesto**.
- → **Convergenza**: **nessuno strumento metodologico è universalmente applicabile** — occorre sempre valutare l'**ambito pertinente**. ### Limiti da segnalare
- **Articolo esterno al corpus IA** in senso stretto — focus su craft / TDD storico. Rilevante indirettamente.
- **Nessun dato empirico** — argomentazione concettuale, non uno studio.
- **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).
- L'**ambito del 30%** è una **stima** non documentata da Eveillard — discutibile a seconda del contesto (un compilatore potrebbe essere all'80% dominio).
- **Impostazione fortemente orientata a FP/esagonale** — può apparire dogmatica agli sviluppatori fortemente radicati in OOP/Rails.
- **Non affronta** il dibattito sull'**impatto del CI/CD sulla strategia di test** che altri autori (in particolare DORA) considerano cruciale. ### Da utilizzare per
- **Sessioni di formazione interne craft / TDD**: materiale didattico di riferimento in lingua francese.
- **Dibattiti di team sul TDD**: argomentazione strutturata per chiarire *Test-first vs TDD*.
- **Collegamento con il corpus 2026 sugli agenti di codifica**: collocare i dibattiti attuali (vibe coding, agenti, AI-augmented) nella **continuità storica** dei dibattiti craft.
- **Sourcing**: l'aforisma *"il TDD non è una religione, è uno strumento"* — una formula sintetica utilizzabile.

## RésuméDe400mots

**Mathieu Eveillard** pubblica il **7 dicembre 2022** (ultimo aggiornamento 17 marzo 2025) sul suo blog personale una **controargomentazione punto per punto** al celebre saggio di **David Heinemeier Hansson** (DHH) *"TDD is dead. Long live testing."* (2014). Articolo classificato `craft / best-of`.

**Distinzione cruciale** che secondo Eveillard sfugge a DHH: ***Test-first*** (scrivere tutti i test prima di qualsiasi codice) vs ***Test-Driven Development*** (i test mi **guidano** nella scrittura del codice, ogni volta scrivo un po' di codice *in reazione* a un nuovo test). DHH in realtà critica il **Test-first** chiamandolo TDD — una confusione che *"nasconde un modo di programmare completamente diverso"*.

**Tre confutazioni**: (1) *TDD come martello per abbattere i non credenti* — Eveillard concede il punto deontologico ma ridefinisce il *"buon codice"* come unit test a grana fine, collocati insieme al codice, una rete di sicurezza; (2) *Riequilibrare dallo unit al system* — il TDD **non dice nulla** sui test di sistema e **non afferma** che non esista nulla al di fuori del TDD; i test di sistema **non sostituiscono** gli unit test (una dichiarazione dei redditi testata end-to-end = assurdo); **piramide dei test** — gli unit test per un feedback in millisecondi + individuazione precoce dei bug; (3) *Mostruosità architetturali orrende (service object, command pattern)* — Eveillard non riscontra questi effetti nella **programmazione funzionale**, quindi è attribuibile all'OOP, non al TDD.

**Conclusione equilibrata**: ***"Il TDD non è una religione, è uno strumento."*** Il TDD è particolarmente adatto al **codice di dominio** (il nucleo funzionale di un *bounded context*, il *cuore dell'esagono*) — motori di calcolo, regole di business a grana fine, casi limite ovunque — ovvero ***"al massimo il 30% della codebase"***. Cita la **Legge dello Strumento** (se lo strumento non aiuta, è perché si è caduti nella trappola del martello).

**Rilevanza per il corpus di veille IA**: un **articolo di craft esterno al corpus IA** in senso stretto ma che risuona con **Kent Beck** (Vibe Coding vs TDD 2024-10 + Augmented Coding 2025-06), l'*atrofia del muscolo della scrittura* di **Frizzo**, il *Cognitive Surrender* di **Osmani** (PR limitate a 100 righe + tempo solitario alla tastiera), **Lattice** (granularità fine atomi/molecole). **Convergenza etica** su *"strumento, non religione"* con **Karpathy** (jagged intelligence), **DORA** (*"tutti i modelli sono sbagliati ma utili"*), **Talisman** (*"il lavoro non può essere saltato"*). **Convergenza sull'ambito limitato** con il **35-40% greenfield vs ≤10% brownfield di Stanford** e il *Frontend > Backend > Infra > Research* di **Ng**.

Da utilizzare per sessioni di formazione craft interne, dibattiti di team sul TDD, collegamento con il corpus 2026 sugli agenti di codifica, per attingere a un aforisma sintetico.

## GrapheDeConnaissance

- Mathieu Eveillard —publie→ TDD is dead. Long live testing. (réponse à DHH) (DOCUMENT, 0.97)
- Mathieu Eveillard —s_oppose_à→ David Heinemeier Hansson (DHH) (PERSONNE, 0.96)
- David Heinemeier Hansson (DHH) —publie→ TDD is dead. Long live testing. (article original, 2014) (DOCUMENT, 0.97)
- Test-first —est_variante_de→ Test-Driven Development (METHODOLOGIE, 0.96)
- Mathieu Eveillard —affirme_que→ DHH critique Test-first en l'appelant TDD (AFFIRMATION, 0.95)
- Mathieu Eveillard —affirme_que→ le TDD n'est pas une religion, c'est un outil (AFFIRMATION, 0.96)
- Test-Driven Development —s_applique_à→ Code domaine / bounded context / cœur hexagone (CONCEPT, 0.94)
- Mathieu Eveillard —affirme_que→ le code domaine TDD-pertinent représente 30% de la codebase au plus (AFFIRMATION, 0.91)
- Tests unitaires —permet→ feedback millisecondes + détection bug précoce (CONCEPT, 0.95)
- Mathieu Eveillard —affirme_que→ les tests système ne remplacent pas les tests unitaires (AFFIRMATION, 0.95)
- Tests unitaires + intégration + acceptance + e2e —fait_partie_de→ Pyramide de tests (CONCEPT, 0.94)
- Programmation fonctionnelle —réduit→ service objects + command patterns monstrosities (CONCEPT, 0.91)
- Trop d'injection de dépendances —permet→ couplage test implémentation (CONCEPT, 0.93)
- Loi de l'Instrument —s_applique_à→ TDD utilisé inappropriément (CONCEPT, 0.92)
- Bilan Eveillard —converge_avec→ Beck Vibe Coding vs TDD, Beck Augmented Coding, Frizzo writing muscle, Osmani Cognitive Surrender (CONCEPT, 0.9)
- Position outil_pas_religion —converge_avec→ Karpathy jagged intelligence, DORA all models wrong, Talisman work cannot be skipped (CONCEPT, 0.89)

---
Canonical: https://www.thekb.eu/it/fiches/eveillard-tdd-is-dead-long-live-testing-reponse-dhh-2022-12-07/