Entrada de tipo **Skill** (no un artículo): `grill-with-docs` de Matt Pocock es una técnica de entrevista estructurada que "somete a la parrilla" un plan de arquitectura confrontándolo metódicamente con el vocabulario de negocio del proyecto (el glosario `CONTEXT.md`) y las decisiones ya documentadas (ADRs). En lugar de precipitarse hacia la implementación, cuestiona las hipótesis una por una mediante un diálogo de preguntas y respuestas, depura la terminología, verifica la coherencia con el código real y registra las decisiones sobre la marcha en los artefactos adecuados. Una skill de diseño previo (upfront design), inspirada en el Domain-Driven Design.
**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.
#Mathieu Eveillard#TDD#Test-driven development
**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"*).