Idea principal

Escribir primero el test y después el código invierte el orden habitual, pero el interés no está en el orden. El test describe el qué: este es el comportamiento esperado, esto es lo que debe seguir siendo cierto. El código describe el cómo. El primero es, por tanto, una pieza de la especificación, escrita en un lenguaje que la máquina puede evaluar.

Lo que esto cambia se ve con el tiempo. El código se refactorizará, se encontrará con datos nuevos, se añadirán otras funcionalidades a su alrededor. El comportamiento esperado, en cambio, queda fijado en otro sitio que la memoria de quien lo implementó: si se rompe, el test se rompe, idealmente en el puesto del desarrollador o en preproducción antes que en producción.

El TDD no elimina los defectos, no sustituye a la reflexión de producto y no convierte una mala especificación en un buen producto. Hace una sola cosa, y es poco común: vuelve verificable una parte de la calidad antes de que exista el código.

Capa aportada por "Ontology-Driven Design: ¿y si la ontología se convirtiera en la red de seguridad del código generado por IA?" (2026-10-29). La misma lógica de anterioridad puede extenderse a la parte del comportamiento esperado que ningún test formaliza: el modelo del negocio. Antes de que un agente como Claude Code escriba el código de una funcionalidad, la petición se contrasta con la ontología del dominio —conceptos, reglas, estados— y las contradicciones se resuelven antes de quedar codificadas. El orden es el mismo que el del TDD; la garantía no, ya que el veredicto procede de un análisis hecho por un LLM y no de una aserción determinista.

Por qué es importante

Esto saca la disciplina del terreno de la higiene técnica. Un test escrito antes es un artefacto de especificación y, por tanto, un lugar donde producto y desarrollo pueden ponerse de acuerdo sobre un comportamiento, algo que un documento en prosa no permite, porque no es evaluable.

Desplaza también el coste de los tests: escritos después, constatan lo que el código hace; escritos antes, restringen lo que deberá hacer.

Matices y límites

La parte formalizable es estrecha. Un test dice que un comportamiento se cumple, nunca que era el comportamiento correcto al que apuntar: la porción de calidad que depende del juicio de producto queda intacta.

Y la disciplina supone que se sepa enunciar el comportamiento esperado. Ante una especificación demasiado vaga, escribir primero el test no aclara nada: congela la ambigüedad en lugar de resolverla.

Preguntas abiertas

• ¿Qué parte de un control basado en el modelo del negocio puede alcanzar una fiabilidad suficiente para cumplir el papel de un test, sin tener su garantía determinista?