Nivel inicial11 min de lectura · Publicado el 13 de julio de 2018

Qué es BDD: guía rápida con Gherkin y newsletter BDD Addict

Qué es BDD, en palabras sencillas

BDD, Behavior-Driven Development (o Behaviour-Driven Development, en inglés británico), desarrollo guiado por comportamiento en español, es una forma de trabajar en la que el equipo describe con ejemplos concretos lo que debe hacer el software antes de programarlo, y después convierte esos ejemplos en pruebas automáticas.

Una petición vaga cada uno la entiende a su manera; un ejemplo concreto se puede comprobar. Cualquiera puede leerlo y ver si el resultado es el esperado.

BDD aplica esa idea al software. En vez de pedir «que el envío sea gratis en pedidos grandes», el equipo acuerda ejemplos concretos:

• Con un carrito de 30 euros, el envío cuesta 5 euros.
• Con un carrito de 50 euros, el envío es gratis.

Esos ejemplos sirven a la vez de especificación (lo que hay que construir), de prueba (lo que se comprueba) y de documentación (lo que hace hoy el sistema).

Y no se quedan en un documento: alguien conecta cada frase con un poco de código (los pasos o step definitions), y desde ahí cada ejemplo se ejecuta como test y avisa cuando el código deja de cumplirlo.

Primero el ejemplo, después el código.

De dónde viene

BDD lo propuso Dan North en «Introducing BDD» (publicado en la revista Better Software en 2006). Lo creó porque a los programadores que empezaban con TDD (desarrollo dirigido por tests) les costaba saber qué probar, cómo llamar a cada test o por dónde empezar. Su idea fue cambiar la palabra «test» por «comportamiento»: en vez de pensar qué probar, piensas qué debe hacer el sistema.

De ese artículo vienen dos plantillas que hoy se usan en todas partes:

North también propuso nombrar los tests como frases que empiezan por should («debería»). Si el nombre no encaja en esa frase, quizá ese comportamiento pertenece a otra clase.

Las tres prácticas de BDD

La documentación de Cucumber divide BDD en tres prácticas que se repiten en pequeñas iteraciones:

1. Descubrir: negocio, desarrollo y pruebas conversan con ejemplos reales para entender qué hace falta y encontrar huecos.
2. Formular: los ejemplos acordados se escriben en Gherkin, un formato que leen tanto las personas como las máquinas.
3. Automatizar: cada ejemplo se conecta al código como una prueba que falla hasta que el comportamiento existe.

La parte más valiosa es la primera. Si te saltas la conversación y solo escribes Gherkin, tienes pruebas con otra sintaxis, no BDD.

Given, When, Then: cómo se escribe un escenario

Cada ejemplo de BDD es un escenario, y se cuenta como una escena de teatro en tres tiempos. La referencia de Gherkin de Cucumber los describe así:

Dos consejos de esa misma referencia evitan los errores más comunes:

• El Then comprueba lo que se ve, no detalles internos como un registro en la base de datos.
• El escenario no habla de botones ni de tecnología. Los detalles de cómo se hace van en el código de los pasos, no en el texto. «Calculo el envío» aguanta un rediseño de la web; «pulso el botón azul» no.

Un ejemplo que puedes ejecutar

Gherkin está traducido a más de 70 idiomas, también al español. Basta con indicar el idioma en la primera línea. Este es el fichero features/envio.feature:

# language: es
Característica: Envío gratis
  Como cliente de la tienda
  quiero saber cuándo no pago el envío
  para animarme a completar el pedido

  Escenario: Pedido por debajo del mínimo
    Dado un carrito con productos por valor de 30 euros
    Cuando calculo el envío
    Entonces el envío cuesta 5 euros

  Escenario: Pedido que llega al mínimo
    Dado un carrito con productos por valor de 50 euros
    Cuando calculo el envío
    Entonces el envío es gratis

Cada frase se conecta con código en los «pasos» (features/step_definitions/envio.steps.mjs). Los {int} recogen el número de la frase:

import { Given, When, Then } from '@cucumber/cucumber';
import assert from 'node:assert/strict';
import { costeEnvio } from '../../src/envio.mjs';

Given('un carrito con productos por valor de {int} euros', function (total) {
  this.total = total;
});

When('calculo el envío', function () {
  this.envio = costeEnvio(this.total);
});

Then('el envío cuesta {int} euros', function (esperado) {
  assert.equal(this.envio, esperado);
});

Then('el envío es gratis', function () {
  assert.equal(this.envio, 0);
});

Y el código que cumple los ejemplos (src/envio.mjs):

const MINIMO_ENVIO_GRATIS = 50;
const TARIFA_ENVIO = 5;

export function costeEnvio(totalCarrito) {
  return totalCarrito >= MINIMO_ENVIO_GRATIS ? 0 : TARIFA_ENVIO;
}

Los ficheros usan la extensión .mjs, así que Node los carga como módulos de JavaScript sin tocar el package.json. Para instalar Cucumber con la versión fijada y ejecutarlo:

npm install --save-dev --save-exact @cucumber/[email protected]
npx cucumber-js

2 scenarios (2 passed)
6 steps (6 passed)

Si alguien cambia >= por >, el segundo escenario falla y te dice qué frase dejó de cumplirse. Esta es la salida real, recortada (sin el detalle de la diferencia ni la traza):

Failed scenarios:
  1) Pedido que llega al mínimo # features/envio.feature:12
       Entonces el envío es gratis # features/step_definitions/envio.steps.mjs:17
           AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

           5 !== 0

2 scenarios (1 passed, 1 failed)
6 steps (5 passed, 1 failed)

El ejemplo ha detectado un error en el límite que un lector con prisa habría pasado por alto.

Las palabras clave en español que más vas a usar:

Puedes ver la lista completa con npx cucumber-js --i18n-keywords es.

BDD vs TDD vs ATDD

Las tres escriben el ejemplo o el test antes que el código. Cambia a qué nivel trabajan y quién participa:

En la práctica, ATDD y BDD se solapan mucho: los escenarios de BDD suelen hacer el papel de los tests de aceptación, y por dentro se sigue programando con TDD. Tienes la comparación completa y un ejemplo paso a paso en qué es ATDD, desarrollo dirigido por tests de aceptación, y el ciclo de TDD en TDD, desarrollo dirigido por test.

Los escenarios nacen muchas veces de los criterios de aceptación de una historia de usuario: más sobre ellas en historias de usuario en Scrum.

Escenarios BDD como especificación para un agente de IA

Esto es criterio propio del enfoque IA Limpia, no algo que digan North ni Cucumber.

Un agente de IA se parece a un compañero nuevo muy rápido que no estuvo en la reunión: lo que no esté escrito, lo supone. Un escenario en Gherkin le da justo lo que le falta, porque dice qué debe pasar con ejemplos concretos y él mismo puede comprobar si lo ha conseguido ejecutando npx cucumber-js.

Para que funcione:

1. Los escenarios los acuerdan y revisan personas antes de pedir el código. El agente puede proponer casos que se os han escapado, pero no decide cuáles entran.
2. Escríbelos en el lenguaje del negocio, sin botones ni nombres de funciones. Si el escenario dicta la implementación, el agente se limita a copiarla y deja de servir como especificación.
3. El agente escribe los pasos y la implementación, no los escenarios. Si cree que uno está mal, para y pregunta; se corrige en la conversación del equipo, no en silencio.
4. Deja la regla escrita donde el agente la lea siempre. Un fichero AGENTS.md o CLAUDE.md puede decir qué orden ejecuta los escenarios y que la carpeta features/ no se toca sin permiso.

Tiene límites: el agente solo cumple lo que describen los escenarios, y puede dejarlos en verde con un código que nadie entiende. Por eso hace falta más de un ejemplo por regla y revisar el resultado como el de cualquier compañero. Una plantilla de encargo para el agente está en el apartado de tests de aceptación como especificación para un agente de IA del artículo de ATDD.

Es la misma idea que el spec-driven development, con una ventaja: el escenario no solo se lee, se ejecuta.

El newsletter: BDD Addict

Este artículo nació en 2018 como un enlace a un newsletter dedicado solo a BDD:

https://www.specsolutions.eu/news/bddaddict/

Es BDD Addict, una selección de artículos, charlas y eventos sobre BDD. Lo edita Gáspár Nagy, creador de SpecFlow y coautor, con Seb Rose, de la serie de libros «The BDD Books». Trata BDD, Cucumber, Reqnroll (el sucesor de SpecFlow para .NET), automatización de pruebas y documentación viva.

Alternativas al newsletter

• Documentación de BDD de Cucumber: gratuita, mantenida y en inglés. Explica las tres prácticas con ejemplos y es un buen sitio para empezar.
• Effective Behavior-Driven Development, de Gáspár Nagy y Seb Rose (Manning): recoge el contenido de «The BDD Books». Está en acceso anticipado desde octubre de 2025 y Manning prevé publicarlo en enero de 2027. En inglés y de pago.

Fuentes

Comprobado el 7 de noviembre de 2026, salvo donde se indica:

• BDD Addict Newsletter, página oficial en Spec Solutions: número más reciente, el 61 (abril de 2024); los números se publican en el blog de Gáspár Nagy, gasparnagy.com. Su autoría y su papel en SpecFlow y en «The BDD Books» (con Seb Rose), en su perfil de Leanpub.
• Dan North, «Introducing BDD» (2006): origen de BDD, nombres con should y plantillas de historia y de escenario.
• Cucumber, Behaviour-Driven Development (las tres prácticas) y referencia de Gherkin (para qué sirven Given, When y Then, palabras clave y traducciones), releídas el 14 de noviembre de 2026.
• Reqnroll: marco BDD para .NET, sucesor de SpecFlow.
• Manning, Effective Behavior-Driven Development: autores, acceso anticipado y fecha prevista. Que recoge «The BDD Books», en bddbooks.com.

Ejecutado el 14 de noviembre de 2026 con Node 24.21.0, npm 11.19.0, @cucumber/cucumber 13.3.0 (la última versión publicada ese día) y @cucumber/gherkin 42.0.1, en Linux. Las palabras clave en español salen de npx cucumber-js --i18n-keywords es en esa misma versión.