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

## Veille

**Mathieu Eveillard** publica en su blog personal el **7 de diciembre de 2022** (última actualización el 17 de marzo de 2025) una **contraargumentación punto por punto** al célebre ensayo de **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Artículo categorizado **craft / best-of**, una postura de **artesano del software** que defiende el **Test-Driven Development** sin dogmatismo. **Distinción crucial** que a DHH se le escapa según Eveillard: ***"Test-first"*** (escribir todos los tests antes de cualquier código) frente a ***"Test-Driven Development"*** (los tests me **guían** en la escritura del código, de modo que cada vez escribo un fragmento de código *"en reacción"* a un nuevo test). DHH en realidad critica el *Test-first* llamándolo TDD — una confusión que **oculta una forma de programar completamente distinta**. **Respuestas punto por punto**: (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concede el punto deontológico pero redefine el *"buen código"*: no solo la ausencia de bugs sino **tests unitarios de grano fino** que documentan el comportamiento en el nivel más bajo, ubicados junto al código, una **red de seguridad**; (2) *"Rebalance from unit to system"* — TDD **no dice nada** sobre los tests de sistema y **no dice** que no haya nada fuera de TDD; los tests de sistema **no sustituyen** a los tests unitarios (una declaración de la renta probada de extremo a extremo no tiene sentido); **pirámide de tests** — cada tipo aporta su parte, los tests unitarios para un feedback de **milisegundos** + detección temprana de bugs; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard responde que **no observa estos efectos en programación funcional**, por lo que el efecto probablemente se deba a la **POO**, no al TDD; pero concede que una inyección de dependencias excesiva puede acoplar test e implementación. **Conclusión equilibrada**: *"TDD is not a religion, it's a tool"*. TDD es especialmente adecuado para el **código de dominio** (el núcleo funcional de un *bounded context*, el *core del hexágono*) — motores de cálculo, reglas de negocio de grano fino, casos límite por doquier — ***"30% del código base como máximo"***. Menciona la **Law of the Instrument** (si la herramienta no ayuda, es porque has caído en ella). **Relevancia para el corpus**: un **artículo de craft ajeno al corpus de IA** pero que vale la pena archivar para situar los debates actuales sobre agentes de codificación (*Augmented Coding Beyond Vibes* de Beck, 2025-06-25, Vibe Coding vs TDD, la *atrofia del músculo de la escritura* de Frizzo) dentro del linaje histórico de los debates de craft en torno al TDD. Para usar como **base de biblioteca** para sesiones de formación.

## 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, contraargumentación a DHH, David Heinemeier Hansson, TDD is dead long live testing 2014, distinción Test-first vs Test-driven development, tests unitarios de bajo nivel, red de seguridad, pirámide de tests, feedback de milisegundos, detección temprana de bugs, programación funcional, inyección de dependencias, acoplamiento test-implementación, código de dominio, bounded context, core del hexágono, hammer to beat down nonbelievers, rebalance from unit to system, horrendous monstrosities of architecture, service objects command patterns, religión vs herramienta, Law of the Instrument, 30 por ciento del código base, Glenn Gould pianista, craft, best-of, software craftsmanship, blog de Mathieu Eveillard, 7 de diciembre de 2022, actualización 17 de marzo de 2025, conexión con los debates sobre agentes de codificación 2025-2026, 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

**Perfil**: Artículo individual de blog de craft, formato de ensayo polémico ponderado y extenso, tono de un **artesano del software humilde pero firme**. Público objetivo: desarrolladores de nivel intermedio a senior, tech leads, formadores de craft, lectores de DHH/Rails curiosos por conocer la otra cara del argumento. Público secundario: managers que intentan comprender los debates internos del equipo sobre TDD.

**Estilo**: Voz en primera persona en francés, **registro conversacional cortés** (*"dudo que el caballero espere alguna respuesta de mi parte"*), estructurado en **3 secciones** correspondientes a las 3 citas de DHH elegidas. Sin ataques ad hominem: Eveillard reconoce a DHH como *"un personaje polifacético"* (creador de Ruby on Rails + ganador de las 24 Horas de Le Mans), elogia sus ideas *"iconoclastas"*, pero refuta con firmeza las conclusiones. **Argumentación punto por punto** en la gran tradición retórica. Metáforas cuidadosamente elaboradas (Glenn Gould como pianista no académico, el *core del hexágono*, el *core del reactor*).

**Aforismos clave**:
- ***"TDD is not a religion, it's a tool."*** (la conclusión crucial).
- ***"Ten en cuenta que podría estar equivocado, y que lo que es bueno para mí no es necesariamente bueno para otra persona."*** (la humildad del artesano).
- ***"Cuanto antes se detecta un bug, menos cuesta."*** (la justificación económica del TDD).
- ***"Al final, esto solo representa una pequeña parte del código base, un 30% como máximo."*** (el alcance razonable del TDD).

**Metáforas elaboradas**:
- ***Red de seguridad*** — los tests como una red que protege contra las regresiones.
- ***Pirámide de tests*** — cada tipo de test aporta su parte a la estructura (referencia a Mike Cohn).
- ***Core del hexágono / core del reactor*** — referencia a la **arquitectura hexagonal** (Alistair Cockburn) — el núcleo funcional de un bounded context.
- ***Glenn Gould, pianista no académico*** — analogía artística: un gran intérprete puede salirse de las convenciones académicas y seguir produciendo un resultado magistral. Permite a Eveillard concederle a DHH que **el resultado importa por encima de todo**.
- ***Law of the Instrument*** — si la herramienta no ayuda, es porque has caído en la trampa de Maslow (*"si lo único que tienes es un martillo, todo parece un clavo"*).

**Postura epistémica**: **equilibrada y autocrítica**. Eveillard:
1. Concede puntos a DHH (ética, ausencia de señalamientos, el resultado importa).
2. **Aclara la confusión** entre Test-first y TDD.
3. Limita **el alcance del TDD al 30% del código base** (código de dominio).
4. Rechaza simultáneamente el **dogmatismo del TDD** y el **rechazo del TDD**.

**Autoridad**: construida mediante (a) **precisión técnica** (distinciones Test-first/TDD, hexagonal, bounded context, FP), (b) **rigor retórico** — punto por punto, sin hombres de paja, (c) **humildad explícita** (*"podría estar equivocado"*), (d) **referencias internas del blog** (DDD estratégico vs táctico, malentendido sobre DevOps) que muestran un cuerpo de trabajo coherente. Limitación: **autoridad de blog individual** sin validación institucional o empírica.

## Pense-betes

- **Fecha / fuente**: **7 de diciembre de 2022** (inicial), **17 de marzo de 2025** (última actualización). Blog personal **mathieueveillard.com**. Categorías: `craft`, `best-of`.
- **Autor**: **Mathieu Eveillard** — desarrollador / craft coach / formador.
- **Objetivo**: DHH, *"TDD is dead. Long live testing."* (RailsConf 2014, publicación de Signal v Noise).
- **Tesis crucial**: ***TDD is not a religion, it's a tool***. Y DHH en realidad critica el ***Test-first***, no el **TDD**. ### La distinción crucial de Eveillard | Concepto | Definición | |---------|-----------| | **Test-first** | Escribo **todos** los tests **antes** de escribir una sola línea de código | | **Test-Driven Development** | Los tests me **guían** en la escritura del código — cada vez escribo un fragmento de código **en reacción** a un nuevo test | > *"Es una lástima que esta confusión nunca se aclare, porque oculta una forma de programar completamente distinta."* ### Las 3 refutaciones punto por punto #### (1) *"TDD as a hammer to beat down the nonbelievers"* **DHH**: TDD usado como un martillo para señalar a los no creyentes, para declararlos poco profesionales. **Eveillard concede**: no tiene sentido señalar con el dedo, contrasta con la humildad del artesano. **Pero redefine el "buen código"**:
- Más allá de la ausencia de bugs;
- **Tests unitarios** que documentan el comportamiento en el nivel más bajo;
- **Ubicados junto al** código;
- **Red de seguridad** — *"Cuanto más fina es la malla, mejor se evitan las regresiones"*. #### (2) *"Rebalance the testing spectrum from unit to system"* **DHH**: desplazamiento de los tests unitarios (con mocks) hacia los tests de sistema. **Eveillard responde**:
- TDD **no prohíbe** nada más allá de los tests unitarios.
- Los tests de sistema **no sustituyen** a los tests unitarios (una declaración de la renta probada de extremo a extremo = absurdo).
- **Pirámide de tests** — cada tipo aporta su propio valor:
- Tests unitarios = feedback de **milisegundos** → guía la escritura del código mediante TDD;
- Detección temprana de bugs → menor coste. **Sobre la arquitectura**: *"horrendous monstrosities (service objects, command patterns)"* — Eveillard no observa estos efectos en **programación funcional**, por lo que es atribuible a la **POO**, no al TDD. #### (3) *"I do not write software test-first"* **DHH**: utiliza *"Test first"* aunque el título anuncia TDD. **Eveillard señala** la **confusión semántica** entre Test-first y TDD como el fallo fundamental del argumento de DHH. ### El alcance razonable del TDD > *"TDD es especialmente adecuado para el código de dominio, el núcleo funcional de un bounded context. El core del hexágono, el core del reactor. Un motor de cálculo, reglas de negocio de grano fino, casos límite por doquier. Ahí, no sé cómo hacerlo si no es con TDD. Pero, al final, esto solo representa una pequeña parte del código base, un 30% como máximo."* | Código | ¿TDD relevante? | |------|----------------| | Dominio / reglas de negocio / motor de cálculo | **CLARAMENTE SÍ** | | Código pegamento / orquestación / IO | Menos | | UI / boilerplate de framework | No es necesario | | **Estimación de Eveillard** | **30% del código base como máximo** | ### Conexión con el corpus de veille #### Relevancia para el corpus de IA / agentes de codificación 2025-2026 El artículo es de **2022** (por tanto, anterior a la explosión de los agentes de codificación) pero **resuena** con los debates actuales:
- **Kent Beck — Vibe Coding vs TDD** (2024-10-17): Beck observa que el vibe coding y el TDD no son mutuamente excluyentes — TDD sigue siendo relevante para el código de dominio, exactamente la postura de Eveillard.
- **Beck — Augmented Coding Beyond Vibes** (2025-06-25): la postura del *"augmented coding"* se apoya en **guardrails** (tests) que el TDD proporciona de forma natural.
- **Frizzo** *Year With Claude Code* (2026-05-05): *"writing muscle atrophy"* — mantener una práctica de TDD es precisamente un antídoto contra la atrofia de la práctica manual.
- **Osmani Cognitive Surrender** (2026-05-05): *"PRs de ~100 líneas como máximo"*, **tiempo de teclado en solitario** — converge con la idea de Eveillard de que el TDD mantiene al desarrollador **dentro de la práctica metodológica del oficio**.
- **Lattice** (2026-05-05): Átomos / Moléculas / Refiners — grano fino, exactamente lo que fomenta el TDD. #### Convergencia "herramienta, no religión"
- **Eveillard**: *"TDD is not a religion, it's a tool."*
- **Karpathy** (2026-04-29): *"jagged intelligence"* — una herramienta con límites de eficacia.
- **DORA ROI 2026** (2026-04-21): *"all models are wrong but useful"* — humildad metodológica.
- **Talisman Ontology Pipeline Refresh** (2026-05-04): *"the work cannot be skipped"* — la metodología como herramienta disciplinaria.
- → **Convergencia ética**: rechazo tanto del **dogmatismo** COMO del **rechazo** de una herramienta metodológica. #### Convergencia "alcance limitado"
- **Eveillard**: TDD = 30% del código base como máximo (código de dominio).
- **Stanford** (citado por DORA): 35-40% de productividad greenfield vs ≤10% brownfield — **distribución desigual según el contexto**.
- **Ng The Batch #350** (2026-04-24): Frontend > Backend > Infra > Research — **aceleración diferencial según el contexto**.
- → **Convergencia**: **ninguna herramienta metodológica es universalmente aplicable** — siempre hay que evaluar el **alcance pertinente**. ### Limitaciones a señalar
- **Artículo ajeno al corpus de IA** en sentido estricto — centrado en craft / TDD histórico. Relevante de forma indirecta.
- **Sin cifras empíricas** — argumentación conceptual, no un estudio.
- **Sin conexión con los agentes de codificación** en la versión de 2025 (la actualización de marzo de 2025 no parece haber incorporado el debate sobre IA/agentes).
- El **alcance del 30%** es una **estimación** no fundamentada por Eveillard — discutible según el contexto (un compilador podría ser 80% dominio).
- **Marco fuertemente orientado hacia FP/hexagonal** — puede parecer dogmático para desarrolladores muy arraigados en POO/Rails.
- **No aborda** el debate sobre el **impacto de CI/CD en la estrategia de testing** que otros autores (DORA en particular) consideran crítico. ### Para usar en
- **Sesiones internas de formación en craft / TDD**: material didáctico de referencia en francés.
- **Debates de equipo sobre TDD**: argumentación estructurada para aclarar *Test-first vs TDD*.
- **Conexión con el corpus de agentes de codificación 2026**: situar los debates actuales (vibe coding, agentes, IA aumentada) dentro de la **continuidad histórica** de los debates de craft.
- **Fuente**: el aforismo *"TDD is not a religion, it's a tool"* — una fórmula sintética utilizable.

## RésuméDe400mots

**Mathieu Eveillard** publica el **7 de diciembre de 2022** (última actualización el 17 de marzo de 2025) en su blog personal una **contraargumentación punto por punto** al célebre ensayo de **David Heinemeier Hansson** (DHH) *"TDD is dead. Long live testing."* (2014). Artículo categorizado `craft / best-of`.

**Distinción crucial** que a DHH se le escapa según Eveillard: ***Test-first*** (escribir todos los tests antes de cualquier código) frente a ***Test-Driven Development*** (los tests me **guían** en la escritura del código, cada vez escribo un fragmento de código *en reacción* a un nuevo test). DHH en realidad critica el **Test-first** llamándolo TDD — una confusión que *"oculta una forma de programar completamente distinta"*.

**Tres refutaciones**: (1) *TDD as hammer to beat down the nonbelievers* — Eveillard concede el punto deontológico pero redefine el *"buen código"* como tests unitarios de grano fino, ubicados junto al código, una red de seguridad; (2) *Rebalance from unit to system* — TDD **no dice nada** sobre los tests de sistema y **no dice** que no haya nada fuera de TDD; los tests de sistema **no sustituyen** a los tests unitarios (una declaración de la renta probada de extremo a extremo = absurdo); **pirámide de tests** — los tests unitarios para un feedback de milisegundos + detección temprana de bugs; (3) *Horrendous monstrosities of architecture (service objects, command patterns)* — Eveillard no observa estos efectos en **programación funcional**, por lo que es atribuible a la POO, no al TDD.

**Conclusión equilibrada**: ***"TDD is not a religion, it's a tool."*** TDD es especialmente adecuado para el **código de dominio** (el núcleo funcional de un *bounded context*, el *core del hexágono*) — motores de cálculo, reglas de negocio de grano fino, casos límite por doquier — es decir ***"30% del código base como máximo"***. Menciona la **Law of the Instrument** (si la herramienta no ayuda, es porque has caído en la trampa del martillo).

**Relevancia para el corpus de veille de IA**: un **artículo de craft ajeno al corpus de IA** en sentido estricto pero que resuena con **Kent Beck** (Vibe Coding vs TDD 2024-10 + Augmented Coding 2025-06), la *atrofia del músculo de la escritura* de **Frizzo**, la *Cognitive Surrender* de **Osmani** (PRs limitados a 100 líneas + tiempo de teclado en solitario), **Lattice** (grano fino átomos/moléculas). **Convergencia ética** en torno a *"herramienta, no religión"* con **Karpathy** (jagged intelligence), **DORA** (*"all models are wrong but useful"*), **Talisman** (*"the work cannot be skipped"*). **Convergencia de alcance limitado** con el **35-40% greenfield vs ≤10% brownfield de Stanford** y el *Frontend > Backend > Infra > Research* de **Ng**.

Para usar en sesiones internas de formación en craft, debates de equipo sobre TDD, articulación con el corpus de agentes de codificación 2026, fuente de un aforismo sintético.

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