Introducción a Gherkin y BDD

El problema que BDD intenta resolver

Imaginá este diálogo en una empresa de software:

PM: Implementamos el login.

QA: ¿Probaron el caso de la contraseña expirada?

Dev: No estaba en los requisitos.

PM: Pensé que era obvio.

Este patrón se repite en miles de equipos. Los requisitos en prosa libre dejan huecos. Los tests unitarios prueban implementación, no comportamiento. Los stakeholders no leen ni Java ni Pytest.

Behaviour-Driven Development (BDD) intenta cerrar la brecha conectando tres conversaciones: la del producto, la del desarrollo y la del testing.

El origen: Dan North y la pregunta “¿por dónde empiezo a testear?”

A mediados de los 2000, Dan North estaba enseñando TDD a equipos. Descubrió un patrón:

• Los newbies preguntaban “¿qué testeo primero?”
• Los seniors decían “el comportamiento, no el código”
• Pero faltaba un lenguaje compartido para describir comportamiento

North experimentó con gramáticas en lenguaje natural que describieran el comportamiento esperado del sistema desde el punto de vista del usuario. La estructura que emergió:

Given <some context>
When <some event>
Then <some outcome>

Tres palabras clave. Cualquiera podía leerlas, cualquiera podía escribirlas.

North escribió JBehave en 2003 — primer framework BDD. Aspiró Smalltalk, Eiffel y RSpec (Ruby BDD framework de Dave Astels y Steven Baker).

Cucumber y Gherkin

En 2008, Aslak Hellesøy quería usar JBehave en Ruby pero quería separar los escenarios del código de tests. Inventó Cucumber, donde los escenarios viven en archivos .feature y se mapean a step definitions en Ruby.

El lenguaje que usaron en los archivos .feature se llamó Gherkin (un tipo de pepinillo — chiste interno con “Cucumber”).

Gherkin:

• Es agnóstico de lenguaje (Ruby, Java, JS, Python, C#, Go, Rust…)
• Es localizable (existe en 70+ idiomas, incluyendo español)
• Está estructurado pero legible (no es código)
• Se mapea uno a uno con tests automatizados

Specification by Example

Gojko Adzic popularizó el término Specification by Example (2011): especificá lo que el sistema hace mediante ejemplos concretos, no abstracciones.

En lugar de:

El sistema debe permitir descuentos según el plan del cliente.

Decí:

Un cliente plan “Free” comprando 100 dólares no recibe descuento. Un cliente plan “Pro” comprando 100 dólares recibe 10 dólares de descuento. Un cliente plan “Premium” comprando 100 dólares recibe 25 dólares de descuento.

Los ejemplos concretos son menos ambiguos que las reglas abstractas. Gherkin formaliza esos ejemplos.

Lenguaje ubicuo y los Three Amigos

Eric Evans introdujo el lenguaje ubicuo en Domain-Driven Design (2003): un vocabulario compartido entre dominio, desarrollo y testing. Gherkin operativiza ese vocabulario:

• El PM dice “el usuario agrega un producto al carrito” → así queda escrito en el feature
• El developer escribe la step definition que ejecuta esa frase
• El test dice exactamente lo mismo
• El reporte dice exactamente lo mismo

Three Amigos: sesiones donde un representante de cada perspectiva (producto, desarrollo, testing) discute un escenario antes de implementarlo. El output del Three Amigos es un set de escenarios Gherkin acordados.

Anatomía mínima

Un archivo .feature:

Feature: Login

  Scenario: Usuario existente con credenciales válidas
    Given un usuario registrado con email "[email protected]" y password "secret123"
    When envía POST /auth/login con email "[email protected]" y password "secret123"
    Then la respuesta tiene status 200
    And el cuerpo contiene un token JWT

Tres bloques:

1. Feature: agrupa escenarios relacionados
2. Scenario: un caso de prueba
3. Steps (Given/When/Then/And): los pasos del caso

Cada step se mapea a una función en código (step definition). Si todos los steps pasan, el escenario pasa.

BDD vs TDD

flowchart LR
    subgraph TDD
        T1[Test unitario falla] --> T2[Implementación pasa el test]
        T2 --> T3[Refactor]
        T3 --> T1
    end
    subgraph BDD
        B1[Conversación con stakeholders] --> B2[Escenarios Gherkin]
        B2 --> B3[Step definitions falla]
        B3 --> B4[Implementación end-to-end]
        B4 --> B5[Escenario pasa]
    end

• TDD opera al nivel de unidad (función, clase). Lo escriben developers.
• BDD opera al nivel de comportamiento del sistema. Lo escriben Three Amigos.

No son alternativas — son complementarios. Equipos maduros hacen TDD por dentro y BDD por fuera (Double Loop TDD).

Cuándo usar Gherkin

Sí:

• Test de aceptación de features (E2E o integración)
• Cuando stakeholders no técnicos validan criterios
• Cuando hay alto valor en documentación viva
• Cuando los AC se discuten en sesiones cross-funcionales
• Cuando hay agentes de IA generando o validando criterios

No (o no necesariamente):

• Tests unitarios de funciones puras (usar Vitest, Jest, pytest directo)
• Tests de implementación específica (mocks de DB, validación de SQL)
• Throwaway scripts sin stakeholders

Ecosistema

Herramienta	Lenguaje	Notas
Cucumber-JS	JavaScript/TS	Mainstream en JS, mantenido por Cucumber Ltd
behave	Python	Mainstream en Python
Cucumber-Ruby	Ruby	El original
SpecFlow	C# / .NET	Cucumber para .NET
Godog	Go	Cucumber para Go
Cucumber-JVM	Java/Kotlin	Cucumber para JVM
pytest-bdd	Python	Alternativa a behave, integra con pytest

Este tutorial cubre Cucumber-JS (TypeScript) y behave (Python). Los conceptos transfieren a cualquier framework BDD.

Resumen

• BDD: conversación → escenarios → tests
• Gherkin: lenguaje natural estructurado para escenarios
• Three Amigos: producto + desarrollo + testing acuerdan AC
• Specification by Example: ejemplos concretos > reglas abstractas
• Living documentation: la spec es el test, el test es la spec

En el siguiente capítulo cubrimos la anatomía completa de un archivo .feature.