¿Qué es Gherkin (Given, When, Then)?

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).