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

## Veille

**Mathieu Eveillard** publishes on his personal blog on **December 7, 2022** (last updated March 17, 2025) a **point-by-point counter-argument** to the famous essay by **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Article categorized **craft / best-of**, a **software craftsman** stance that defends **Test-Driven Development** without dogmatism. **Pivotal distinction** that DHH misses according to Eveillard: ***"Test-first"*** (writing all the tests before any code) vs ***"Test-Driven Development"*** (tests **guide** me in writing code, so each time I write a bit of code *"in reaction"* to a new test). DHH actually criticizes *Test-first* while calling it TDD — a confusion that **hides an entirely different way of programming**. **Point-by-point responses**: (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concedes the deontological point but redefines *"good code"*: not just the absence of bugs but **fine-grained unit tests** documenting behavior at the lowest level, co-located with the code, a **safety net**; (2) *"Rebalance from unit to system"* — TDD **says nothing** about system tests and **does not say** there is nothing outside TDD; system tests do **not replace** unit tests (an income tax return tested end-to-end makes no sense); **test pyramid** — each type contributes its share, unit tests for **millisecond** feedback + early bug detection; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard responds that he **does not see these effects in functional programming**, so the effect is likely due to **OOP**, not TDD; but concedes that excessive dependency injection can couple test and implementation. **Balanced conclusion**: *"TDD is not a religion, it's a tool"*. TDD is particularly well suited to **domain code** (the functional core of a *bounded context*, the *core of the hexagon*) — calculation engines, fine-grained business rules, edge cases galore — ***"30% of the codebase at most"***. Mentions the **Law of the Instrument** (if the tool doesn't help, it's because you've fallen into it). **Relevance to the corpus**: a **craft article outside the AI corpus** but worth archiving to position current debates on coding agents (Beck's *Augmented Coding Beyond Vibes*, 2025-06-25, Vibe Coding vs TDD, Frizzo's *writing muscle atrophy*) within the historical lineage of craft debates around TDD. To be used as a **library foundation** for training sessions.

## 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, DHH counter-argument, David Heinemeier Hansson, TDD is dead long live testing 2014, Test-first vs Test-driven development distinction, low-level unit tests, safety net, test pyramid, millisecond feedback, early bug detection, functional programming, dependency injection, test-implementation coupling, domain code, bounded context, core of the hexagon, hammer to beat down nonbelievers, rebalance from unit to system, horrendous monstrosities of architecture, service objects command patterns, religion vs tool, Law of the Instrument, 30 percent codebase, Glenn Gould pianist, craft, best-of, software craftsmanship, Mathieu Eveillard blog, December 7, 2022, March 17, 2025 update, connection with 2025-2026 coding agents debates, 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

**Profile**: Individual craft blog article, long-form measured polemical essay format, tone of a **humble but firm software craftsman**. Target audience: intermediate to senior developers, tech leads, craft trainers, DHH/Rails readers curious about the other side of the argument. Secondary audience: managers trying to understand internal team debates on TDD.

**Style**: First-person voice in French, **courteous conversational register** (*"I doubt the gentleman expects any response from me"*), structured into **3 sections** corresponding to the 3 chosen DHH quotes. No ad hominem: Eveillard acknowledges DHH as *"a multi-faceted character"* (creator of Ruby on Rails + winner of the 24 Hours of Le Mans), praises his *"iconoclastic"* ideas, but firmly refutes the conclusions. **Point-by-point argumentation** in the great rhetorical tradition. Carefully crafted metaphors (Glenn Gould as a non-academic pianist, the *core of the hexagon*, the *core of the reactor*).

**Key aphorisms**:
- ***"TDD is not a religion, it's a tool."*** (the pivotal conclusion).
- ***"Keep in mind that I could be wrong, and that what's good for me isn't necessarily good for someone else."*** (the craftsman's humility).
- ***"The earlier a bug is detected, the less it costs."*** (the economic justification for TDD).
- ***"In the end, this represents only a small part of the codebase, 30% at most."*** (the reasonable scope of TDD).

**Elaborated metaphors**:
- ***Safety net*** — tests as a net protecting against regressions.
- ***Test pyramid*** — each type of test contributes its share to the structure (reference to Mike Cohn).
- ***Core of the hexagon / core of the reactor*** — reference to **hexagonal architecture** (Alistair Cockburn) — the functional core of a bounded context.
- ***Glenn Gould, non-academic pianist*** — artistic analogy: a great performer can step outside academic conventions while still producing a masterful result. Allows Eveillard to concede to DHH that **the result matters above all**.
- ***Law of the Instrument*** — if the tool doesn't help, it's because you've fallen into the Maslow trap (*"if all you have is a hammer, everything looks like a nail"*).

**Epistemic stance**: **balanced and self-critical**. Eveillard:
1. Concedes points to DHH (ethics, no finger-pointing, the result matters).
2. **Clears up the confusion** between Test-first and TDD.
3. Limits **TDD's scope to 30% of the codebase** (domain code).
4. Simultaneously rejects **TDD dogmatism** and the **rejection of TDD**.

**Authority**: built through (a) **technical precision** (Test-first/TDD, hexagonal, bounded context, FP distinctions), (b) **rhetorical rigor** — point-by-point, no strawmanning, (c) **explicit humility** (*"I could be wrong"*), (d) **internal blog references** (strategic vs tactical DDD, DevOps misunderstanding) showing a coherent body of work. Limitation: **individual blog authority** without institutional or empirical validation.

## Pense-betes

- **Date / source**: **December 7, 2022** (initial), **March 17, 2025** (last updated). Personal blog **mathieueveillard.com**. Categories: `craft`, `best-of`.
- **Author**: **Mathieu Eveillard** — developer / craft coach / trainer.
- **Target**: DHH, *"TDD is dead. Long live testing."* (RailsConf 2014, Signal v Noise post).
- **Pivotal thesis**: ***TDD is not a religion, it's a tool***. And DHH actually criticizes ***Test-first***, not **TDD**. ### Eveillard's pivotal distinction | Concept | Definition | |---------|-----------| | **Test-first** | I write **all** the tests **before** writing a single line of code | | **Test-Driven Development** | Tests **guide** me in writing code — each time I write a bit of code **in reaction** to a new test | > *"It's a shame this confusion is never cleared up, because it hides an entirely different way of programming."* ### The 3 point-by-point refutations #### (1) *"TDD as a hammer to beat down the nonbelievers"* **DHH**: TDD used as a hammer to point at non-believers, to declare them unprofessional. **Eveillard concedes**: no point in pointing fingers, contrasts with the craftsman's humility. **But redefines "good code"**:
- Beyond the absence of bugs;
- **Unit tests** documenting behavior at the lowest level;
- **Co-located** with the code;
- **Safety net** — *"The finer the mesh, the better regressions are avoided"*. #### (2) *"Rebalance the testing spectrum from unit to system"* **DHH**: shift from unit tests (with mocks) to system tests. **Eveillard responds**:
- TDD **does not prohibit** anything beyond unit tests.
- System tests do **not replace** unit tests (an income tax return tested end-to-end = absurd).
- **Test pyramid** — each type contributes its own value:
- Unit tests = **millisecond** feedback → guides code writing via TDD;
- Early bug detection → lower cost. **On architecture**: *"horrendous monstrosities (service objects, command patterns)"* — Eveillard does not see these effects in **functional programming**, so it is attributable to **OOP**, not TDD. #### (3) *"I do not write software test-first"* **DHH**: uses *"Test first"* even though the title announces TDD. **Eveillard points to** the **semantic confusion** between Test-first and TDD as the fundamental flaw in DHH's argument. ### The reasonable scope of TDD > *"TDD is particularly well suited to domain code, the functional core of a bounded context. The core of the hexagon, the core of the reactor. A calculation engine, fine-grained business rules, edge cases everywhere. There, I don't know how to do it other than with TDD. But in the end, this represents only a small part of the codebase, 30% at most."* | Code | TDD relevant? | |------|----------------| | Domain / business rules / calculation engine | **STRONGLY YES** | | Glue code / orchestration / IO | Less so | | UI / framework boilerplate | Not required | | **Eveillard's estimate** | **30% of codebase max** | ### Connection to the watch corpus #### Relevance to the AI / coding agents 2025-2026 corpus The article is from **2022** (so before the coding agents explosion) but **resonates** with current debates:
- **Kent Beck — Vibe Coding vs TDD** (2024-10-17): Beck observes that vibe coding and TDD are not mutually exclusive — TDD remains relevant for domain code, exactly Eveillard's position.
- **Beck — Augmented Coding Beyond Vibes** (2025-06-25): the *"augmented coding"* stance relies on **guardrails** (tests) that TDD naturally provides.
- **Frizzo** *Year With Claude Code* (2026-05-05): *"writing muscle atrophy"* — maintaining a TDD practice is precisely an antidote to the atrophy of manual practice.
- **Osmani Cognitive Surrender** (2026-05-05): *"PRs ~100 lines max"*, **solo keyboard time** — converges with Eveillard's idea that TDD keeps the developer **within the methodological practice of the craft**.
- **Lattice** (2026-05-05): Atoms / Molecules / Refiners — fine granularity, exactly what TDD encourages. #### "Tool, not religion" convergence
- **Eveillard**: *"TDD is not a religion, it's a tool."*
- **Karpathy** (2026-04-29): *"jagged intelligence"* — a tool with boundaries of effectiveness.
- **DORA ROI 2026** (2026-04-21): *"all models are wrong but useful"* — methodological humility.
- **Talisman Ontology Pipeline Refresh** (2026-05-04): *"the work cannot be skipped"* — methodology as a disciplinary tool.
- → **Ethical convergence**: rejecting both **dogmatism** AND the **rejection** of a methodological tool. #### "Limited scope" convergence
- **Eveillard**: TDD = 30% of codebase max (domain code).
- **Stanford** (cited by DORA): 35-40% productivity greenfield vs ≤10% brownfield — **uneven distribution by context**.
- **Ng The Batch #350** (2026-04-24): Frontend > Backend > Infra > Research — **differential acceleration by context**.
- → **Convergence**: **no methodological tool is universally applicable** — always assess the **relevant scope**. ### Limitations to flag
- **Article outside the AI corpus** strictly speaking — focus on craft / historical TDD. Relevant indirectly.
- **No empirical figures** — conceptual argumentation, not a study.
- **No engagement with coding agents** in the 2025 version (the March 2025 update does not appear to have incorporated the AI/agents debate).
- The **30% scope** is an **estimate** not sourced by Eveillard — debatable depending on context (a compiler could be 80% domain).
- **Frame strongly oriented toward FP/hexagonal** — may seem dogmatic to developers strongly rooted in OOP/Rails.
- **Does not address** the **CI/CD impact on testing strategy** debate that other authors (DORA in particular) consider critical. ### To be used for
- **Internal craft / TDD training sessions**: reference French-language teaching material.
- **Team debates on TDD**: structured argumentation to clarify *Test-first vs TDD*.
- **Connection with the 2026 coding agents corpus**: positioning current debates (vibe coding, agents, AI-augmented) within the **historical continuity** of craft debates.
- **Sourcing**: the aphorism *"TDD is not a religion, it's a tool"* — a usable synthetic formula.

## RésuméDe400mots

**Mathieu Eveillard** publishes on **December 7, 2022** (last updated March 17, 2025) on his personal blog a **point-by-point counter-argument** to the famous essay by **David Heinemeier Hansson** (DHH) *"TDD is dead. Long live testing."* (2014). Article categorized `craft / best-of`.

**Pivotal distinction** that DHH misses according to Eveillard: ***Test-first*** (writing all the tests before any code) vs ***Test-Driven Development*** (tests **guide** me in writing code, each time I write a bit of code *in reaction* to a new test). DHH actually criticizes **Test-first** while calling it TDD — a confusion that *"hides an entirely different way of programming"*.

**Three refutations**: (1) *TDD as hammer to beat down the nonbelievers* — Eveillard concedes the deontological point but redefines *"good code"* as fine-grained, co-located unit tests, a safety net; (2) *Rebalance from unit to system* — TDD **says nothing** about system tests and **does not say** there is nothing outside TDD; system tests **do not replace** unit tests (an income tax return tested end-to-end = absurd); **test pyramid** — unit tests for millisecond feedback + early bug detection; (3) *Horrendous monstrosities of architecture (service objects, command patterns)* — Eveillard does not see these effects in **functional programming**, so it is attributable to OOP, not TDD.

**Balanced conclusion**: ***"TDD is not a religion, it's a tool."*** TDD is particularly well suited to **domain code** (the functional core of a *bounded context*, the *core of the hexagon*) — calculation engines, fine-grained business rules, edge cases galore — that is ***"30% of the codebase at most"***. Mentions the **Law of the Instrument** (if the tool doesn't help, it's because you've fallen into the hammer trap).

**Relevance to the AI watch corpus**: a **craft article outside the AI corpus** strictly speaking but resonates with **Kent Beck** (Vibe Coding vs TDD 2024-10 + Augmented Coding 2025-06), **Frizzo**'s *writing muscle atrophy*, **Osmani**'s *Cognitive Surrender* (PRs capped at 100 lines + solo keyboard time), **Lattice** (fine granularity atoms/molecules). **Ethical convergence** on *"tool, not religion"* with **Karpathy** (jagged intelligence), **DORA** (*"all models are wrong but useful"*), **Talisman** (*"the work cannot be skipped"*). **Limited-scope convergence** with **Stanford's 35-40% greenfield vs ≤10% brownfield** and **Ng**'s *Frontend > Backend > Infra > Research*.

To be used for internal craft training sessions, team debates on TDD, articulation with the 2026 coding agents corpus, sourcing a synthetic aphorism.

## 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/en/fiches/eveillard-tdd-is-dead-long-live-testing-reponse-dhh-2022-12-07/