Gherkin vs BDD - Behavior Driven Development (Desarrollo Guiado por Comportamiento)

Gherkin es un lenguaje estructurado y legible que sirve para describir el comportamiento de un sistema de software con frases en lenguaje casi natural. Su objetivo es que cualquier persona del equipo, incluidos los perfiles no técnicos, pueda leer y entender qué debe hacer una funcionalidad sin necesidad de mirar el código.

La pieza central de Gherkin es la estructura Given, When, Then (en español: Dado, Cuando, Entonces). Esas tres palabras clave describen, respectivamente, el contexto de partida, la acción que ocurre y el resultado esperado. Esa secuencia ordena cualquier escenario de uso en una narrativa sencilla que sirve a la vez como especificación, como documentación viva y como base para pruebas automatizadas.

Gherkin es el lenguaje habitual del Desarrollo Dirigido por Comportamiento (BDD), una práctica que busca alinear a negocio, desarrollo y QA alrededor de ejemplos concretos del comportamiento esperado. La idea es conversar sobre lo que el sistema debe hacer antes de escribir código, y dejar esa conversación plasmada en escenarios que todos entienden.

Su valor principal es eliminar ambigüedad. Un requisito escrito en prosa suele interpretarse de varias maneras; un escenario Gherkin fija un ejemplo verificable: dado este estado, cuando ocurre esta acción, entonces este resultado. Por eso encaja de forma natural con los criterios de aceptación de una historia de usuario: cada criterio se puede expresar como uno o varios escenarios que demuestran cuándo la historia está realmente terminada.

A diferencia del TDD (Test-Driven Development), que parte de pruebas unitarias escritas por desarrolladores, BDD con Gherkin describe el comportamiento desde la perspectiva del usuario o del negocio, en un lenguaje compartido. Ambos enfoques son complementarios, no excluyentes.

Gherkin organiza la información con un conjunto reducido de palabras clave:

• Feature: la funcionalidad que se describe, con una breve explicación de su propósito.
• Scenario: un caso concreto de uso de esa funcionalidad.
• Given: el contexto o estado inicial antes de la acción.
• When: la acción o evento que dispara el comportamiento.
• Then: el resultado que se espera observar.
• And y But: encadenan varios pasos del mismo tipo para no repetir palabras clave.

La estructura Given (contexto inicial), When (acción) y Then (resultado esperado) permite que cualquier persona del equipo lea el escenario sin saber programar. Un ejemplo sencillo:

Feature: Inicio de sesión Scenario: Acceso con credenciales válidas Given un usuario registrado en la aplicación When introduce su email y contraseña correctos Then accede a su panel de control

Cuando varios escenarios comparten el mismo contexto, se puede extraer a un bloque Background. Y cuando un mismo escenario debe probarse con distintos datos, se usa un Scenario Outline con una tabla de Examples, evitando duplicar el texto:

Feature: Validación del importe de una transferencia Scenario Outline: Importes válidos e inválidos Given una cuenta con saldo de <saldo> euros When el cliente intenta transferir <importe> euros Then el sistema responde con "<resultado>" Examples: | saldo | importe | resultado | | 100 | 50 | transferencia ok | | 100 | 150 | saldo insuficiente | | 100 | 0 | importe no válido |

Gherkin por sí solo describe comportamiento; no ejecuta nada. Su potencia aparece cuando se conecta con un motor de automatización como Cucumber, SpecFlow o Behave, que enlaza cada paso del escenario con una función de código (los llamados step definitions). Así, el mismo texto que lee el negocio se convierte en una prueba automática que verifica el comportamiento real en cada cambio.

Como estos escenarios son legibles para todos, suelen nacer durante el refinamiento del backlog y se afinan dentro de un sprint, de modo que el equipo comparte una misma definición de hecho (DoD) antes de cada despliegue. Estas pruebas suelen ejecutarse de forma automática en la canalización de integración continua, lo que las convierte en una red de seguridad que documenta el sistema y al mismo tiempo lo valida.

Algunos fallos habituales al escribir Gherkin:

• Describir clics y campos en lugar de comportamiento. Escribir "When pulso el botón azul de la esquina" ata el escenario a la interfaz. Es mejor expresar la intención: "When confirma la compra". Así el escenario sobrevive a los rediseños.
• Mezclar varias acciones en un solo When. Cada escenario debería probar un comportamiento. Si hay muchos When encadenados, conviene partirlo en escenarios separados.
• Escenarios escritos solo por QA o solo por desarrollo. El valor de Gherkin está en la conversación de las tres partes (negocio, desarrollo y QA). Sin esa conversación, se pierde la mitad del beneficio y queda solo una sintaxis incómoda.
• Dejar los escenarios desincronizados del código. Si los step definitions no se mantienen, la documentación viva deja de ser viva y pasa a engañar. Hay que tratarla como parte del producto.
• Usar Gherkin para todo. No conviene reescribir cada prueba unitaria en escenarios; Gherkin brilla en flujos de negocio observables, no en detalles internos de bajo nivel.

Para profundizar en el contexto donde encaja Gherkin, revisa BDD, los criterios de aceptación, la historia de usuario y la definición de hecho. En el lado de la verificación, son útiles el TDD y las pruebas end-to-end (E2E).

BDD (Behavior Driven Development), o Desarrollo Guiado por Comportamiento, es una metodología de desarrollo de software que busca mejorar la colaboración entre equipos técnicos y de negocio definiendo el comportamiento esperado del sistema en lenguaje natural estructurado antes de escribir código.

BDD fue creado por Dan North en 2006 como una evolución de TDD (Test-Driven Development). Mientras que TDD se centra en escribir pruebas unitarias técnicas antes del código, BDD eleva la perspectiva al nivel del comportamiento del usuario y del negocio, utilizando un lenguaje que todos los involucrados pueden entender.

La idea fundamental de BDD es que el software debe definirse en términos de comportamientos deseados expresados mediante ejemplos concretos, no en términos de especificaciones técnicas abstractas. Estos ejemplos, escritos en formato Given-When-Then (Dado-Cuando-Entonces), se convierten simultáneamente en documentación viva, especificación de requisitos y pruebas automatizadas ejecutables.

BDD cierra la brecha de comunicación entre el qué (lo que el negocio necesita) y el cómo (lo que el equipo técnico construye), asegurando que ambos lados compartan la misma comprensión del comportamiento esperado.

BDD se distingue por varios elementos fundamentales:

Formato Given-When-Then

El corazón de BDD es la estructura Given-When-Then para describir comportamientos:

• Given (Dado): establece el contexto o estado previo del sistema.
• When (Cuando): describe la acción o evento que se produce.
• Then (Entonces): define el resultado esperado que debe verificarse.

Feature: Transferencia bancaria Como cliente del banco Quiero transferir dinero entre mis cuentas Para gestionar mis finanzas cómodamente Scenario: Transferencia exitosa con saldo suficiente Given el cliente tiene una cuenta corriente con 1000 EUR And el cliente tiene una cuenta de ahorro con 500 EUR When el cliente transfiere 200 EUR de la cuenta corriente a la cuenta de ahorro Then la cuenta corriente debe tener 800 EUR And la cuenta de ahorro debe tener 700 EUR And se debe registrar la transacción en el historial Scenario: Transferencia rechazada por saldo insuficiente Given el cliente tiene una cuenta corriente con 100 EUR When el cliente intenta transferir 200 EUR de la cuenta corriente Then la transferencia debe ser rechazada And se debe mostrar el mensaje "Saldo insuficiente" And la cuenta corriente debe mantener 100 EUR

Lenguaje Gherkin

Gherkin es el lenguaje formal utilizado para escribir escenarios BDD. Sus características principales son:

• Legible por humanos no técnicos.
• Soporta múltiples idiomas (español, inglés, francés, etc.).
• Estructurado con palabras clave: Feature, Scenario, Given, When, Then, And, But.
• Permite Scenario Outline con tablas de datos para parametrizar pruebas.
• Los archivos tienen extensión .feature.

Las tres amigos (Three Amigos)

BDD promueve sesiones de Three Amigos donde tres perspectivas colaboran para definir comportamientos:

1. Negocio (Product Owner): define qué quiere el usuario y por qué.
2. Desarrollo (Developer): identifica cómo implementar el comportamiento.
3. Testing (QA): identifica casos extremos, errores y escenarios que podrían fallar.

Especificación mediante ejemplos

En lugar de requisitos abstractos como "el sistema debe validar los datos de entrada", BDD utiliza ejemplos concretos:

Scenario Outline: Validación de email When el usuario introduce el email "<email>" Then el sistema debe mostrar "<resultado>" Examples: | email | resultado | | usuario@gmail.com | Email válido | | usuario@ | Email inválido | | @gmail.com | Email inválido | | usuario.com | Email inválido | | user@empresa.co.uk | Email válido |

Veamos el flujo completo de BDD en un proyecto real: el desarrollo de un sistema de descuentos para un e-commerce.

Sesión de Three Amigos:

El Product Owner, un Developer y una QA se reúnen para definir la funcionalidad de cupones de descuento. La conversación se traduce en escenarios:

Feature: Aplicación de cupones de descuento Como comprador en la tienda online Quiero aplicar cupones de descuento a mi carrito Para ahorrar dinero en mis compras Scenario: Cupón de porcentaje válido Given el carrito tiene productos por valor de 100 EUR And existe un cupón "VERANO20" con 20% de descuento When el comprador aplica el cupón "VERANO20" Then el total del carrito debe ser 80 EUR And se debe mostrar "Cupón aplicado: -20 EUR" Scenario: Cupón expirado Given existe un cupón "INVIERNO" que expiró el 2025-12-31 When el comprador intenta aplicar el cupón "INVIERNO" Then el cupón debe ser rechazado And se debe mostrar "Este cupón ha expirado" Scenario: Cupón con importe mínimo no alcanzado Given el carrito tiene productos por valor de 30 EUR And existe un cupón "ENVIOGRATIS" con compra mínima de 50 EUR When el comprador aplica el cupón "ENVIOGRATIS" Then el cupón debe ser rechazado And se debe mostrar "Compra mínima de 50 EUR requerida" Scenario: Solo un cupón por pedido Given el carrito ya tiene aplicado el cupón "VERANO20" When el comprador intenta aplicar otro cupón "FLASH10" Then el segundo cupón debe ser rechazado And se debe mostrar "Solo se permite un cupón por pedido"

Implementación de los Step Definitions (Python + Behave):

from behave import given, when, then @given('el carrito tiene productos por valor de {total:d} EUR') def step_carrito_con_total(context, total): context.carrito = Carrito() context.carrito.agregar_producto(Producto("Item", total)) @given('existe un cupón "{codigo}" con {porcentaje:d}% de descuento') def step_cupon_porcentaje(context, codigo, porcentaje): context.cupones[codigo] = CuponPorcentaje(codigo, porcentaje) @when('el comprador aplica el cupón "{codigo}"') def step_aplicar_cupon(context, codigo): cupon = context.cupones.get(codigo) context.resultado = context.carrito.aplicar_cupon(cupon) @then('el total del carrito debe ser {esperado:d} EUR') def step_verificar_total(context, esperado): assert context.carrito.total == esperado

Ejecución:

$ behave features/cupones.feature Feature: Aplicación de cupones de descuento Scenario: Cupón de porcentaje válido ... passed Scenario: Cupón expirado ... passed Scenario: Cupón con importe mínimo no alcanzado ... passed Scenario: Solo un cupón por pedido ... passed 4 scenarios passed, 0 failed

BDD aporta beneficios significativos al proceso de desarrollo de software:

Comunicación entre silos: el mayor valor de BDD no es técnico, sino comunicativo. Al obligar a los equipos de negocio, desarrollo y QA a sentarse juntos y definir comportamientos en un lenguaje compartido, se eliminan las ambigüedades y malentendidos que son la causa principal de requisitos mal implementados.

Documentación viva: los archivos .feature de BDD sirven simultáneamente como documentación de requisitos y pruebas ejecutables. A diferencia de documentos de Word que quedan obsoletos rápidamente, los escenarios BDD se ejecutan con cada build y fallan si el comportamiento del sistema cambia. La documentación siempre está actualizada porque es código.

Reducción del retrabajo: al definir el comportamiento esperado antes de escribir código, se reducen drásticamente los bugs causados por malentendidos entre negocio y desarrollo. Estudios indican que entre el 40% y el 60% de los defectos de software se originan en requisitos mal comprendidos. BDD ataca directamente esta causa raíz.

Criterios de aceptación claros: los escenarios BDD funcionan como criterios de aceptación verificables. No hay discusión sobre si una funcionalidad "está terminada" o no: si todos los escenarios pasan, la funcionalidad cumple con lo acordado.

Cobertura de casos extremos: la sesión de Three Amigos, con la perspectiva del QA, asegura que se consideren escenarios de error, casos límite y flujos alternativos desde el inicio del diseño, no como hallazgos tardíos durante el testing.

Herramientas BDD por lenguaje

¿Cuál es la diferencia entre BDD y TDD?

TDD escribe pruebas técnicas unitarias antes del código, enfocándose en el diseño interno. BDD escribe escenarios de comportamiento en lenguaje natural antes del código, enfocándose en el valor para el usuario. BDD opera a un nivel de abstracción más alto y es comprensible por personas no técnicas. En la práctica, BDD y TDD son complementarios: BDD para comportamiento externo, TDD para diseño interno.

¿Los escenarios BDD reemplazan las pruebas unitarias?

No. Los escenarios BDD son pruebas de aceptación a nivel de comportamiento del sistema. Las pruebas unitarias verifican el correcto funcionamiento de componentes individuales a nivel técnico. Ambas son necesarias y operan en diferentes niveles de la pirámide de testing.

¿Quién escribe los escenarios BDD?

Idealmente, los escenarios se co-crean en sesiones de Three Amigos. El Product Owner aporta el "qué" y el "por qué", el Developer aporta el "cómo" y el QA aporta los "qué pasa si". La redacción final puede hacerla cualquiera de los tres, pero lo importante es que los tres contribuyan y estén de acuerdo.

¿BDD solo funciona para aplicaciones web?

No. BDD es agnóstico respecto a la tecnología. Se puede aplicar a aplicaciones web, móviles, APIs, sistemas embebidos, microservicios o cualquier tipo de software. Lo que cambia es la implementación de los step definitions, no el enfoque de definir comportamientos.

¿Cuántos escenarios debería tener una Feature?

No hay un número fijo, pero como regla general, una Feature debería tener entre 3 y 10 escenarios. Menos de 3 sugiere que la funcionalidad no está suficientemente explorada. Más de 10 indica que la Feature es demasiado grande y debería dividirse. Los escenarios deben cubrir el flujo principal (happy path), los principales flujos alternativos y los casos de error más relevantes.

¿BDD ralentiza el desarrollo?

A corto plazo, las sesiones de Three Amigos y la escritura de escenarios añaden tiempo al inicio. A medio y largo plazo, BDD ahorra tiempo significativamente al reducir malentendidos, retrabajo, bugs y discusiones sobre si una funcionalidad cumple los requisitos. Los equipos que practican BDD consistentemente reportan menos defectos y mayor velocidad de entrega sostenible.