TDD vs BDD vs SDD: Guía completa de metodologías de desarrollo de software

Comparativa exhaustiva entre Test Driven Development, Behavior Driven Development y Spec Driven Development con definiciones, ejemplos (Red‑Green‑Refactor, Gherkin), ventajas, limitaciones, migración y uso con asistentes de código IA.

1. La evolución de las metodologías de desarrollo ¶

Durante décadas, el desarrollo de software funcionó con un patrón predecible: primero escribes código, después lo pruebas, y finalmente descubres que lo que construiste no era exactamente lo que necesitabas. Un ciclo frustrante que costó millones en proyectos fallidos.

A principios de los 2000, Kent Beck popularizó una idea que parecía contraintuitiva: escribir los tests antes que el código. Así nació el Test Driven Development (TDD), una metodología que invertía el proceso tradicional y prometía código más limpio y menos bugs.

Poco después, Dan North observó que el TDD tenía un problema: los tests técnicos no comunicaban bien la intención del negocio. Su respuesta fue el Behavior Driven Development (BDD), que trasladaba el foco desde los tests unitarios hacia el comportamiento esperado del sistema, usando un lenguaje que todos pudieran entender.

Y ahora, en 2025, nos encontramos ante un nuevo paradigma. Con la irrupción de los asistentes de código basados en IA, ha surgido una pregunta inevitable: ¿cómo especificamos lo que queremos construir cuando una máquina va a escribir gran parte del código? La respuesta es el Spec Driven Development (SDD), una metodología diseñada específicamente para el desarrollo asistido por inteligencia artificial.

Cada una de estas metodologías responde a un problema concreto de su época. Entender sus diferencias te permitirá elegir la herramienta adecuada para cada situación, o incluso combinarlas estratégicamente.

2. Test Driven Development (TDD): El pionero ¶

Qué es TDD ¶

TDD es una práctica de desarrollo donde escribes un test automatizado antes de escribir el código de producción. El proceso sigue un ciclo corto y repetitivo conocido como Red-Green-Refactor:

1. Red: Escribes un test que falla (porque el código aún no existe)
2. Green: Escribes el código mínimo necesario para que el test pase
3. Refactor: Mejoras el código manteniendo los tests en verde

Ejemplo práctico de TDD ¶

Imagina que necesitas crear una función que valide emails. Con TDD, empezarías así:

// 1. RED: Escribimos el test primero
describe('validateEmail', () => {
  it('debe retornar true para un email válido', () => {
    expect(validateEmail('usuario@dominio.com')).toBe(true);
  });

  it('debe retornar false si falta el @', () => {
    expect(validateEmail('usuariodominio.com')).toBe(false);
  });

  it('debe retornar false si falta el dominio', () => {
    expect(validateEmail('usuario@')).toBe(false);
  });
});

Este test fallará porque validateEmail no existe. Ahora escribimos el código mínimo:

// 2. GREEN: Código mínimo para pasar los tests
function validateEmail(email: string): boolean {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

Finalmente, revisamos si hay oportunidades de mejora (refactor) sin romper los tests.

Ventajas del TDD ¶

• Cobertura de tests garantizada: Si sigues el proceso, todo tu código tiene tests
• Diseño emergente: Los tests fuerzan a pensar en la interfaz antes que en la implementación
• Documentación viva: Los tests describen qué hace el código
• Refactoring seguro: Puedes modificar código con confianza

Limitaciones del TDD ¶

• Curva de aprendizaje pronunciada: Requiere práctica para dominar el ciclo
• Puede ralentizar el inicio: Escribir tests primero parece más lento al principio
• Enfoque técnico: Los tests hablan el lenguaje del desarrollador, no del negocio
• Difícil en código legacy: Aplicar TDD a código existente sin tests es complejo

3. Behavior Driven Development (BDD): Enfoque en comportamiento ¶

De TDD a BDD ¶

Dan North creó BDD para resolver un problema que observaba en equipos practicando TDD: los tests estaban escritos en lenguaje técnico que solo entendían los desarrolladores. El negocio quedaba fuera de la conversación.

BDD propone describir el comportamiento del sistema usando un lenguaje natural estructurado, típicamente en formato Given/When/Then (Dado/Cuando/Entonces). Este formato se especifica comúnmente en Gherkin, un lenguaje que pueden leer tanto desarrolladores como personas de negocio.

Ejemplo práctico de BDD con Gherkin ¶

Retomemos el ejemplo del validador de email, pero ahora desde la perspectiva BDD:

Feature: Validación de email de usuario
  Como sistema de registro
  Quiero validar los emails de los usuarios
  Para asegurar que puedo contactarlos

  Scenario: Email con formato válido
    Given un usuario introduce el email "usuario@dominio.com"
    When el sistema valida el email
    Then la validación debe ser exitosa

  Scenario: Email sin arroba
    Given un usuario introduce el email "usuariodominio.com"
    When el sistema valida el email
    Then la validación debe fallar
    And el mensaje de error debe ser "El email debe contener @"

  Scenario: Email sin dominio después del arroba
    Given un usuario introduce el email "usuario@"
    When el sistema valida el email
    Then la validación debe fallar
    And el mensaje de error debe ser "El email debe tener un dominio válido"

Estos escenarios se conectan con código mediante step definitions:

// step-definitions/email.steps.ts
import { Given, When, Then } from '@cucumber/cucumber';
import { validateEmail } from '../src/validateEmail';

let emailInput: string;
let validationResult: { valid: boolean; error?: string };

Given('un usuario introduce el email {string}', (email: string) => {
  emailInput = email;
});

When('el sistema valida el email', () => {
  validationResult = validateEmail(emailInput);
});

Then('la validación debe ser exitosa', () => {
  expect(validationResult.valid).toBe(true);
});

Then('la validación debe fallar', () => {
  expect(validationResult.valid).toBe(false);
});

Then('el mensaje de error debe ser {string}', (expectedError: string) => {
  expect(validationResult.error).toBe(expectedError);
});

Ventajas del BDD ¶

• Lenguaje común: Negocio y desarrollo hablan el mismo idioma
• Documentación ejecutable: Los escenarios Gherkin son especificaciones que se pueden ejecutar
• Enfoque en valor de negocio: Se centra en qué debe hacer el sistema, no en cómo
• Facilita la colaboración: Product owners pueden escribir y revisar escenarios

Limitaciones del BDD ¶

• Overhead inicial significativo: Configurar el framework y escribir step definitions lleva tiempo
• Mantenimiento de steps: Los step definitions pueden volverse difíciles de gestionar
• Tentación de over-engineering: No todo necesita escenarios Gherkin
• Requiere disciplina del equipo: Si negocio no participa, pierde gran parte de su valor

4. Spec Driven Development (SDD): Lo opuesto al vibe coding ¶

El problema del vibe coding ¶

El vibe coding se ha puesto muy de moda: abres un chat con una IA, le pides que te construya una aplicación, vas viendo el resultado y le dices “cámbiame esto”, “ponme este campo”, “quítame aquello”. Generas código sin programar, simplemente dando instrucciones según las “vibras” que te da lo que ves.

El problema es que esto genera software impredecible. No tienes control real sobre lo que la IA decide hacer. Cada iteración puede romper algo anterior. Y cuando el proyecto crece, te encuentras con un código que ni tú ni la IA entienden del todo.

Qué es el Spec Driven Development ¶

SDD es exactamente lo contrario al vibe coding. En lugar de ir improvisando con la IA, defines de antemano qué quieres que haga el software.

El desarrollo guiado por especificaciones es un enfoque para elaborar primero una especificación detallada del comportamiento deseado del software antes de escribir una línea de código. No empezamos programando, sino creando un documento estructurado que describe con todo lujo de detalles qué debe hacer el sistema y cómo debe comportarse en distintos escenarios.

Este documento, la especificación o “spec”, es una fuente de verdad. Pero con una particularidad importante: es fuente de verdad tanto para el equipo humano como para la IA. Es el artefacto principal que describe la intención de lo que queremos en un lenguaje estructurado para que los agentes de IA creen el código que lo construye.

Ejemplo de especificación SDD ¶

Para nuestro validador de email, una especificación SDD sería:

# Especificación: Validador de Email

## Propósito
Validar que un string representa un email con formato correcto
para el sistema de registro de usuarios.

## Contexto
- Se usará en formularios de registro y recuperación de contraseña
- Debe ejecutarse tanto en cliente como en servidor
- No verifica que el email exista, solo el formato

## Interface
function validateEmail(email: string): ValidationResult

type ValidationResult = {
  valid: boolean;
  error?: string;
  normalizedEmail?: string;
}

## Reglas de validación
1. Debe contener exactamente un carácter @
2. La parte local (antes del @) no puede estar vacía
3. El dominio (después del @) debe contener al menos un punto
4. No se permiten espacios en ninguna parte
5. La longitud máxima es 254 caracteres (RFC 5321)

## Casos límite
- Emails con subdominios: válidos (user@mail.empresa.com)
- Emails con + en parte local: válidos (user+tag@dominio.com)
- Emails con mayúsculas: válidos, pero normalizar a minúsculas

## Comportamiento de error
- Retornar error específico según la regla violada
- Un solo error a la vez, en orden de prioridad de las reglas

## No incluye
- Validación de existencia del dominio (DNS lookup)
- Envío de email de verificación
- Almacenamiento del email

Con esta especificación, la IA tiene un contrato claro. No improvisa: construye exactamente lo que le has definido.

Los inconvenientes reales del SDD ¶

Seamos honestos: esto no es mágico y tiene problemas.

El tiempo de documentación. Todo el tiempo que pasas escribiendo especificaciones es tiempo que no estás programando. La acción parece ralentizarse mientras otros te hablan del vibe coding con soluciones mágicas donde “solo con pensar ya tienes el resultado”.

Riesgo de mentalidad waterfall. Si te sometes a la especificación como si fuera sagrada, vuelves al desarrollo rígido de hace décadas. La especificación debe ser flexible: puedes intervenir cuando la IA comete fallos o cuando te das cuenta de que algo no está como querías.

Mantener código Y documentación. Este es el problema principal. A nadie le apetece mantener código y además mantener documentación actualizada. La buena noticia es que las IAs cada vez saben más de tu código echándole un vistazo, con lo cual la especificación puede quedarse implícita en el propio código una vez implementada.

La mentalidad híbrida ¶

Lo que funciona en la práctica es mantener una mentalidad híbrida. Está muy bien dotar de orden a la creación para que cumpla unos requisitos, pero siempre haciéndola flexible. No te olvides de que estás interactuando con un sistema al que puedes decirle “para aquí, esto házmelo de esta otra forma”.

El SDD te da seguridad. Poder confiar en que la IA va a hacer el trabajo como tú quieres, sin tener que sufrir porque se le olvidó poner un tipo en algún sitio y todo se rompe. Eso puede seguir pasando, pero con esto tienes algo parecido a una vara que guía a la IA para que cumpla con tus requisitos.

Si quieres ver cómo aplicar esta metodología paso a paso, con plantillas y ejemplos prácticos, he preparado una guía completa sobre Spec Driven Development donde desarrollo el proceso completo.

5. Tabla comparativa y cuándo usar cada una ¶

Matriz de comparación ¶

Cuándo elegir cada metodología ¶

Elige TDD cuando:

• Trabajas en lógica de negocio compleja con muchos casos límite
• El equipo tiene experiencia con testing y valora el diseño emergente
• Necesitas máxima confianza en refactorizaciones frecuentes
• El proyecto es de larga duración con mantenimiento continuo

Elige BDD cuando:

• Hay stakeholders no técnicos que necesitan entender y validar requisitos
• El dominio del negocio es complejo y requiere lenguaje ubicuo
• Trabajas con equipos grandes donde la comunicación es crítica
• Los requisitos cambian frecuentemente y necesitas documentación viva

Elige SDD cuando:

• Quieres control sobre lo que genera la IA en lugar de improvisar con vibe coding
• Necesitas que la IA siga un contrato claro y no decida por su cuenta
• El proyecto requiere consistencia: la IA debe generar código que siga tus patrones
• Buscas seguridad y predictibilidad en el desarrollo asistido por IA

¿Son excluyentes? ¶

No. De hecho, pueden combinarse estratégicamente:

• SDD + TDD: Crea la especificación, genera código con IA, valida con TDD
• BDD + SDD: Escenarios Gherkin como parte de la especificación para la IA
• Los tres: Especificación general (SDD) → Escenarios de negocio (BDD) → Tests unitarios (TDD)

La clave está en entender qué problema resuelve cada una y aplicarlas donde aporten valor real.

6. Migración entre metodologías ¶

Desde código sin metodología hacia TDD ¶

Si tienes un proyecto legacy sin tests, no intentes aplicar TDD a todo de golpe. La estrategia pragmática es:

1. Identifica zonas de cambio frecuente: Empieza por código que modificas a menudo
2. Escribe tests de caracterización: Tests que documentan el comportamiento actual (aunque sea incorrecto)
3. Aplica TDD en código nuevo: Todo código nuevo sigue el ciclo Red-Green-Refactor
4. Refactoriza gradualmente: Cuando toques código legacy, añade tests antes

Desde TDD hacia BDD ¶

Si tu equipo domina TDD pero necesita mejor comunicación con negocio:

1. Identifica features de alto valor: No todo necesita escenarios Gherkin
2. Empieza con un ejemplo piloto: Una feature pequeña para aprender el proceso
3. Involucra a negocio desde el inicio: Los escenarios se escriben en sesiones colaborativas
4. Mantén tests TDD para lógica interna: BDD para comportamiento de usuario, TDD para implementación

Incorporando SDD a tu flujo actual ¶

SDD no requiere herramientas especiales, pero sí requiere un cambio de mentalidad:

1. Escribe la especificación antes de pedirle nada a la IA: Haz de esto un paso obligatorio
2. Mantén mentalidad híbrida: La spec da orden, pero puedes intervenir cuando la IA falle o cuando cambien los requisitos
3. No te obsesiones con mantener la documentación: Una vez implementado, la spec puede quedar implícita en el código
4. Combina con tests: Usa TDD o BDD para validar que el código generado cumple la especificación

El error más común es querer que la especificación sea sagrada e inmutable. La realidad es que vas a necesitar intervenir: la IA cometerá fallos, te darás cuenta de cosas que no habías previsto, los requisitos cambiarán. La flexibilidad dentro del orden es la clave.

7. Conclusión y próximos pasos ¶

TDD, BDD y SDD no son modas pasajeras ni soluciones mágicas. Son herramientas que resuelven problemas específicos en contextos específicos.

TDD te da confianza para refactorizar y un diseño que emerge de los tests. Es ideal para lógica compleja donde cada caso límite importa.

BDD construye puentes entre negocio y desarrollo con un lenguaje común. Brilla en equipos donde la comunicación es tan importante como el código.

SDD es la respuesta al vibe coding. Cuando la IA puede generar código por ti, tienes dos opciones: improvisar según las “vibras” que te da el resultado, o establecer un contrato claro que la IA debe cumplir. SDD elige la segunda opción, dándote seguridad y control sobre lo que construyes.

Mi recomendación ¶

Si estás empezando, domina primero TDD. Es la base sobre la que se construyen las demás. Una vez que el ciclo Red-Green-Refactor sea natural para ti, explora BDD si trabajas con equipos multidisciplinares.

Y si ya estás usando IA para programar, deja de hacer vibe coding y prueba SDD. No porque sea perfecto (tiene sus inconvenientes: el tiempo de documentación, el riesgo de rigidez, mantener código y specs), sino porque te da algo que el vibe coding no puede: predictibilidad.

Para profundizar ¶

Si te interesa implementar SDD en tu día a día, he preparado una guía práctica completa sobre Spec Driven Development con un formato “Elige tu propia aventura” donde puedes seguir el camino que mejor se adapte a tu situación. Incluye los pasos, los problemas que encontrarás en cada fase, y cómo resolverlos.

El desarrollo de software evoluciona constantemente. Las metodologías que elijas hoy definirán la calidad del código que construyas mañana, ya sea tecleándolo tú mismo o guiando a una IA para que lo haga.