Siempre hay alguien que pregunta si el desarrollo guiado por especificaciones sustituye al desarrollo guiado por tests. La pregunta da por hecho que compiten por el mismo hueco, que eliges una metodología y la otra sobra. Ese supuesto es el error, y lleva a la gente a soltar una de dos cosas que ambas necesitan.
Tests y specs responden a preguntas distintas. Un test pregunta «¿hace el código esta cosa concreta?». Una spec pregunta «¿es esta la cosa que el código debía hacer?». Puedes pasar todos los tests y aun así haber construido la feature equivocada, y puedes tener una spec perfecta y aun así publicar código que la viola. No son dos respuestas a un problema. Son dos problemas distintos que resulta que están uno al lado del otro.
Qué fija cada uno de verdad
El desarrollo guiado por tests fija el comportamiento. Escribes un test que falla, lo haces pasar, refactorizas. El test es una afirmación ejecutable sobre lo que hace el código en un punto concreto, y su gran virtud es que corre. Un test no tiene opiniones ni se olvida. O pasa o no pasa, y sigue comprobando para siempre. Esa es una forma real de verdad, y es la razón por la que los tests siguen siendo carga estructural sin importar cómo se escribió el código.
El desarrollo guiado por especificaciones fija la intención. La spec declara qué debe cambiar, qué tiene que seguir siendo cierto y cómo reconocerás un resultado correcto, y lo hace antes de empezar a construir. Su virtud es que captura la decisión, no solo el comportamiento. Una spec puede decir «los cupones no deben acumularse nunca, es una regla de negocio, no un accidente», que es justo el tipo de cosa que un test hace cumplir pero nunca explica.
Aquí está el hueco entre ambos. Un test puede estar perfectamente en verde y hacer cumplir el comportamiento equivocado, porque el test solo sabe lo que alguien le dijo que comprobara. No puede decirte que el comportamiento que protege es en sí mismo un malentendido de lo que el producto necesitaba. La spec es donde vive ese juicio. Los tests verifican contra un objetivo. La spec es la que puso el objetivo.
Por qué los agentes hacen las capas obligatorias
Con una persona escribiendo cada línea, a veces podías arreglártelas solo con tests, porque la intención vivía en la cabeza de quien programaba y se filtraba en valores por defecto razonables. Un agente no tiene esa cabeza. Tiene el prompt, el contexto que le diste y lo que pueda inferir, y rellenará con toda confianza cualquier hueco que dejaste con una suposición plausible.
Aquí es donde los tests por sí solos dejan de bastar. Un agente puede escribir código, escribir tests para ese código y hacerlos pasar, y todo el bucle puede ser internamente coherente y estar mal igual, porque el agente probó su propia interpretación. Nada comprobó esa interpretación contra tu intención. Es la trampa detrás de un build en verde que no es una feature correcta: el build demuestra que el código está de acuerdo con sus propios tests, no contigo.
La spec rompe ese bucle. Es el único artefacto que el agente no redactó, la intención fija contra la que se miden los tests. Dale a un agente una spec y sus tests tienen algo sobre lo que acertar o fallar. No le des ninguna y sus tests son solo un espejo.
Se enchufan el uno en el otro
En cuanto dejas de plantearlos como rivales, la conexión es obvia. Los criterios de aceptación de la spec son de donde deberían salir los tests. Un criterio como «un cupón caducado se rechaza antes de calcular el total» es una frase en la spec y un test en la suite, y el test existe precisamente para demostrar esa cláusula del contrato.
Así es como consigues criterios de aceptación que un agente puede verificar: los criterios se escriben para ser ejecutables, así que cada uno se convierte en un test en lugar de en una esperanza vaga. La spec pone la intención, los criterios la traducen en afirmaciones comprobables, y los tests hacen la comprobación en cada ejecución. Cada capa hace el trabajo que la otra no puede.
Y funciona en las dos direcciones. Un test difícil de escribir suele significar que un criterio es vago, que suele significar que la intención nunca se fijó de verdad. La fricción de escribir el test saca a la superficie un agujero en la spec. Ese feedback es una de las razones silenciosas por las que las dos disciplinas van mejor juntas que cualquiera por separado.
El orden importa tanto como el emparejamiento. La spec va primero, luego los criterios, luego los tests, luego el código, y cada paso limita al siguiente. Si dejas que el agente escriba el código primero y genere los tests después, los tests heredan lo que el código resultó hacer, sus errores incluidos, y vuelves a un espejo. Escribir los criterios comprobables antes de que el código exista es lo que mantiene los tests independientes de la implementación, para que midan el código contra la intención en lugar de contra sí mismo. El TDD le dio a la industria esa disciplina de orden para el comportamiento. El desarrollo guiado por especificaciones empuja la misma disciplina una capa más arriba, a la intención.
Qué cambia todavía en el testing
Poner las dos en capas no significa que el testing quede intacto ante los agentes. Cuando el código llega más rápido de lo que nadie puede leerlo, los tests cargan con más confianza que antes, así que qué pruebas y cómo confías en ello se desplazan los dos. Ese es su propio tema, tratado en probar código generado por IA: qué cambia y qué no, pero la versión corta es que los tests pasan a ser más estructurales, no menos, precisamente porque una persona revisó menos líneas.
La spec no te salva de eso. Apunta el esfuerzo. Sin la spec, estás probando lo que sea que el agente decidió construir. Con ella, estás probando si el agente construyó lo acordado. Los tests son el mismo mecanismo de un modo u otro. La spec decide si están apuntados al objetivo correcto.
Dónde encaja PaellaDoc
Tratar las dos como capas es el modelo sobre el que está construido PaellaDoc. La spec sostiene la intención y sigue ligada al código que la implementa. Sus criterios de aceptación se conectan con las ejecuciones que los ponen a prueba, así que los tests no son una isla de confianza separada sino el brazo ejecutor del contrato. Cuando el código deriva, puedes ver qué criterios, y por tanto qué tests, están comprobando ahora contra una intención que se movió.
Spec-driven y test-driven nunca pelearon por un solo asiento. Los tests te dicen que el código hace lo que hace. La spec te dice que eso era lo que debía hacer. Suelta cualquiera de los dos y estarás confiando en un bucle que solo se comprueba a sí mismo.
Preguntas frecuentes
¿El desarrollo guiado por especificaciones sustituye al TDD? No. Operan sobre preguntas distintas. El TDD verifica que el código hace una cosa concreta; la spec fija cuál era esa cosa. Quitar los tests pierde tu red de seguridad de comportamiento; quitar la spec pierde la intención a la que los tests deberían servir.
Si tengo buenos tests, ¿por qué necesito además una spec? Porque los tests pueden hacer cumplir el comportamiento equivocado a la perfección. Un test solo comprueba lo que alguien decidió comprobar, y con un agente ese alguien es a menudo el propio agente. La spec es la intención independiente contra la que se miden tus tests.
¿De dónde salen los tests en un flujo guiado por especificaciones? De los criterios de aceptación de la spec. Cada criterio escrito para ser comprobable se convierte en un test, así que la suite existe para demostrar cláusulas concretas del contrato en lugar de la propia interpretación del agente sobre la tarea.