TDD Is Not Dead: A Point-by-Point Rebuttal to DHH

Key takeaways

1. Date / source. December 7, 2022 (initial), March 17, 2025 (last updated). Personal blog mathieueveillard.com. Categories: craft, best-of.
2. Author. Mathieu Eveillard — developer / craft coach / trainer.
3. Target. DHH, "TDD is dead. Long live testing." (RailsConf 2014, Signal v Noise post).
4. 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":
5. Beyond the absence of bugs;
6. Unit tests. documenting behavior at the lowest level;
7. Co-located. with the code;
8. 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:
9. TDD does not prohibit anything beyond unit tests.
10. System tests do not replace unit tests (an income tax return tested end-to-end = absurd).
11. Test pyramid. — each type contributes its own value:
12. Unit tests = millisecond feedback → guides code writing via TDD;
13. 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:
14. 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.
15. Beck — Augmented Coding Beyond Vibes. (2025-06-25): the "augmented coding" stance relies on guardrails (tests) that TDD naturally provides.
16. 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.
17. 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.
18. Lattice. (2026-05-05): Atoms / Molecules / Refiners — fine granularity, exactly what TDD encourages. #### "Tool, not religion" convergence
19. Eveillard. "TDD is not a religion, it's a tool."
20. Karpathy. (2026-04-29): "jagged intelligence" — a tool with boundaries of effectiveness.
21. DORA ROI 2026. (2026-04-21): "all models are wrong but useful" — methodological humility.
22. Talisman Ontology Pipeline Refresh. (2026-05-04): "the work cannot be skipped" — methodology as a disciplinary tool.
23. → Ethical convergence: rejecting both dogmatism AND the rejection of a methodological tool. #### "Limited scope" convergence
24. Eveillard. TDD = 30% of codebase max (domain code).
25. Stanford. (cited by DORA): 35-40% productivity greenfield vs ≤10% brownfield — uneven distribution by context.
26. Ng The Batch #350. (2026-04-24): Frontend > Backend > Infra > Research — differential acceleration by context.
27. → Convergence: no methodological tool is universally applicable — always assess the relevant scope. ### Limitations to flag
28. Article outside the AI corpus. strictly speaking — focus on craft / historical TDD. Relevant indirectly.
29. No empirical figures. — conceptual argumentation, not a study.
30. No engagement with coding agents. in the 2025 version (the March 2025 update does not appear to have incorporated the AI/agents debate).
31. The 30% scope is an estimate not sourced by Eveillard — debatable depending on context (a compiler could be 80% domain).
32. Frame strongly oriented toward FP/hexagonal. — may seem dogmatic to developers strongly rooted in OOP/Rails.
33. Does not address. the CI/CD impact on testing strategy debate that other authors (DORA in particular) consider critical. ### To be used for
34. Internal craft / TDD training sessions. reference French-language teaching material.
35. Team debates on TDD. structured argumentation to clarify Test-first vs TDD.
36. Connection with the 2026 coding agents corpus. positioning current debates (vibe coding, agents, AI-augmented) within the historical continuity of craft debates.
37. Sourcing. the aphorism "TDD is not a religion, it's a tool" — a usable synthetic formula.