Spec-driven development vs TDD y BDD: en qué se diferencian

Spec-driven development, TDD y BDD se diferencian en qué escribes antes del código y en quién lo lee: TDD un test que ejecuta un runner, BDD un ejemplo en lenguaje de negocio que lee una persona, y SDD una especificación que lee un agente de código. No son tres nombres para lo mismo, y tampoco compiten entre sí.

Para seguir el resto solo necesitas dos palabras. Un test automático es un trozo de código que comprueba que otro hace lo que dices, y el runner de tests es el programa que los ejecuta todos y te dice cuáles fallan.

Metodología	Qué escribes primero	Dónde vive	Quién lo lee	Has terminado cuando
TDD	Un test que falla	Un fichero de test junto al código, en el repositorio	El runner de tests. Ninguna persona lo lee de arriba abajo	El test pasa y has limpiado el código sin romperlo
BDD	Un ejemplo del comportamiento, escrito en lenguaje de negocio	Un fichero .feature en Gherkin, o el propio nombre de los tests	Una persona: producto, QA, el cliente. Y después una librería que lo ejecuta	El escenario se cumple y todo el mundo entiende por qué
SDD	Una especificación de la intención: qué hay que construir y con qué restricciones	Un documento markdown versionado en git, al lado del código	Un agente de código, y tú cuando revisas lo que ha producido	La implementación cumple la spec y la spec sigue describiendo el sistema

Si tras leer la última fila todavía no tienes claro qué va dentro de una spec, empieza por qué es spec-driven development y vuelve aquí.

TDD y BDD: el test y el ejemplo

TDD (test-driven development) es un ciclo de tres pasos que Kent Beck codificó a finales de los noventa dentro de Extreme Programming: rojo, verde, refactor. Escribes un test que falla porque la función todavía no existe. Escribes el código mínimo para que pase. Y solo entonces limpias lo que has escrito, sin cambiar el comportamiento.

// TDD: primero el test, que falla porque total() aún no existe (rojo)
test('un carrito vacío suma 0', () => {
  const carrito = nuevoCarrito();   // el estado de partida
  expect(total(carrito)).toBe(0);   // lo que esperas que ocurra
});
// Después escribes total() hasta que pase (verde), y ahí lo limpias (refactor)

BDD nació de ahí. Dan North lo bautizó como behaviour-driven development en 2003, trabajando en ThoughtWorks, porque enseñando TDD se topaba siempre con la misma confusión: la gente no sabía qué testear ni qué significaba que un test fallara. Su respuesta fue cambiar el vocabulario. Donde había “test”, comportamiento. Donde había comprobaciones sueltas dentro del código, ejemplos que una persona puede leer sin ser programadora.

De ahí sale el formato Given/When/Then, y más tarde Gherkin, el lenguaje de los ficheros .feature que ejecuta Cucumber. Este es el mismo caso del test de arriba, escrito para que lo lea alguien de producto:

# language: es
Característica: Carrito de la compra
  Escenario: Carrito vacío
    Dado que el carrito no tiene productos
    Cuando consulto el total
    Entonces el total es 0

Lo que cambia es el lector.

SDD: la especificación que lee el agente

El spec-driven development sube un escalón más: en lugar de un caso, describes la intención completa de un cambio antes de que nadie escriba una línea. Qué hay que construir, qué restricciones aplican, qué queda explícitamente fuera y qué se considera hecho. Y el lector ya no es un runner ni un compañero de producto, sino un agente de código: un modelo que lee ficheros, escribe código y ejecuta comandos por su cuenta.

Ese cambio de lector es toda la diferencia. Un test le dice al agente que algo falla, pero nunca le dice qué estabas intentando construir.

El término se popularizó durante 2025 alrededor de estas herramientas, y el origen del término lo cuento aparte. GitHub liberó Spec Kit en septiembre de ese año, y hay varias opciones más con pesos muy distintos, que comparo en qué framework de specs elegir. Por qué una spec sostiene un proyecto mejor que una sucesión de prompts lo desarrollo en la guía larga de spec-driven development.

Cuándo compensa cada uno

TDD compensa cuando la lógica es tuya y es delicada: cálculos, reglas de negocio, cualquier sitio donde un caso límite mal resuelto se paga caro en producción.

Con BDD el problema ya no está en el código sino en el acuerdo. Si producto y desarrollo entienden cosas distintas por “el usuario puede cancelar el pedido”, escribir el ejemplo juntos antes de programar te ahorra dos iteraciones.

El caso de SDD es otro: la implementación no la escribimos nosotros. Delegar en un agente sin spec es pedirle que adivine, y adivina bien durante un rato hasta que deja de hacerlo.

Por qué no tienes que elegir

Seguimos planteándolo como si hubiera que elegir, y ninguna de las tres ocupa el sitio de otra: cada una opera en una capa distinta. La spec dice qué hay que construir. El ejemplo de BDD dice cómo se comporta el sistema visto desde fuera. El test de TDD dice si una unidad concreta hace su trabajo. Y domain-driven design juega en una cuarta capa perpendicular: modela el dominio del problema y el vocabulario que comparten negocio y desarrollo, no el orden en el que trabajas.

La combinación que mejor nos está funcionando es escribir una spec con un criterio de aceptación explícito, lo que la implementación tiene que cumplir para darse por buena: esto se implementa con tests primero, y no se da por terminado hasta que la suite entera pase en verde. Ahí SDD dirige al agente y TDD le pone la condición de salida. El agente escribe el test, lo ve fallar y luego escribe el código. Es el ciclo de toda la vida, solo que quien teclea es otro.

Si lo que te interesa es cómo trabaja por dentro ese agente que lee la spec, qué decide y dónde se equivoca, es justo lo que cubro en el curso de patrones agénticos.

Preguntas Frecuentes

¿El spec-driven development sustituye a TDD?

No. Uno describe qué hay que construir y el otro comprueba que una pieza concreta funciona, así que conviven en el mismo repositorio sin estorbarse.

¿Se pueden combinar spec-driven development y TDD?

Sí, y es la combinación que mejor funciona cuando la implementación la hace un agente. La spec lleva el alcance, las restricciones y una línea literal como esta:

Criterio de aceptación: cobertura de los casos límite de total() con tests
que fallen antes de existir la implementación; no se cierra hasta que la
suite pase en verde.

Con esa línea el agente tiene objetivo y condición de parada. Sin ella decide por su cuenta cuándo ha terminado, y su criterio y el tuyo no siempre coinciden.

¿Qué diferencia hay entre spec-driven development y DDD?

DDD es domain-driven design, el enfoque que Eric Evans publicó en 2003, y va de modelar el dominio del problema y compartir un vocabulario común entre negocio y desarrollo. No dice nada sobre en qué orden escribes las cosas. SDD sí: es un orden de trabajo, la spec antes que el código, y no un modo de modelar. Se usan juntos sin fricción.

¿SDD es volver al waterfall?

No, porque no operan al mismo nivel: waterfall congela los requisitos de todo el proyecto antes de empezar, y una spec fija el orden de un solo cambio, del tamaño de una pull request. La objeción completa, con los casos en los que sí degenera en waterfall, la desmonto en la guía larga de spec-driven development.