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

Puntos clave

1. 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.
2. Autor. Mathieu Eveillard — desarrollador / craft coach / formador.
3. Objetivo. DHH, "TDD is dead. Long live testing." (RailsConf 2014, publicación de Signal v Noise).
4. 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":
5. Más allá de la ausencia de bugs;
6. Tests unitarios. que documentan el comportamiento en el nivel más bajo;
7. Ubicados junto al. código;
8. 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:
9. TDD no prohíbe nada más allá de los tests unitarios.
10. Los tests de sistema no sustituyen a los tests unitarios (una declaración de la renta probada de extremo a extremo = absurdo).
11. Pirámide de tests. — cada tipo aporta su propio valor:
12. Tests unitarios = feedback de milisegundos → guía la escritura del código mediante TDD;
13. 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:
14. 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.
15. 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.
16. 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.
17. 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.
18. Lattice. (2026-05-05): Átomos / Moléculas / Refiners — grano fino, exactamente lo que fomenta el TDD. #### Convergencia "herramienta, no religión"
19. Eveillard. "TDD is not a religion, it's a tool."
20. Karpathy. (2026-04-29): "jagged intelligence" — una herramienta con límites de eficacia.
21. DORA ROI 2026. (2026-04-21): "all models are wrong but useful" — humildad metodológica.
22. Talisman Ontology Pipeline Refresh. (2026-05-04): "the work cannot be skipped" — la metodología como herramienta disciplinaria.
23. → Convergencia ética: rechazo tanto del dogmatismo COMO del rechazo de una herramienta metodológica. #### Convergencia "alcance limitado"
24. Eveillard. TDD = 30% del código base como máximo (código de dominio).
25. Stanford. (citado por DORA): 35-40% de productividad greenfield vs ≤10% brownfield — distribución desigual según el contexto.
26. Ng The Batch #350. (2026-04-24): Frontend > Backend > Infra > Research — aceleración diferencial según el contexto.
27. → Convergencia: ninguna herramienta metodológica es universalmente aplicable — siempre hay que evaluar el alcance pertinente. ### Limitaciones a señalar
28. Artículo ajeno al corpus de IA. en sentido estricto — centrado en craft / TDD histórico. Relevante de forma indirecta.
29. Sin cifras empíricas. — argumentación conceptual, no un estudio.
30. 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).
31. El alcance del 30% es una estimación no fundamentada por Eveillard — discutible según el contexto (un compilador podría ser 80% dominio).
32. Marco fuertemente orientado hacia FP/hexagonal. — puede parecer dogmático para desarrolladores muy arraigados en POO/Rails.
33. 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
34. Sesiones internas de formación en craft / TDD. material didáctico de referencia en francés.
35. Debates de equipo sobre TDD. argumentación estructurada para aclarar Test-first vs TDD.
36. 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.
37. Fuente. el aforismo "TDD is not a religion, it's a tool" — una fórmula sintética utilizable.