BDD con Cucumber y Gherkin desde cero

El desarrollo guiado por comportamiento es una forma de trabajar en la que se describe qué debe hacer el sistema, en términos de comportamiento observable y en un lenguaje que todo el equipo puede leer, antes de programarlo. La diferencia con escribir pruebas normales no está tanto en la herramienta como en el propósito y el momento: una prueba normal la escribe y la lee el equipo técnico para verificar código, mientras que un escenario de BDD está pensado para que también lo lean y acuerden las personas de negocio, y sirve a la vez de especificación, documentación y prueba. Ese mismo texto se convierte después en una prueba automática. La clave es que BDD aporta cuando esa conversación entre roles ocurre de verdad; si el escenario solo lo lee el equipo técnico, la diferencia con una prueba normal se reduce a sintaxis extra.

Son dos piezas complementarias. Gherkin es el lenguaje: un formato estructurado con pocas palabras clave —Feature, Scenario, Given, When, Then y algunas más— con el que se escribe un escenario legible que describe un comportamiento, casi como prosa. Por sí solo, ese texto no ejecuta nada: es una descripción. Cucumber es la herramienta que lo vuelve ejecutable, conectando cada paso escrito en Gherkin con una definición de paso, que es el bloque de código que hace realmente lo que el paso dice. Cucumber lee el escenario, encuentra para cada paso su definición correspondiente por coincidencia de texto, y la ejecuta en orden, convirtiendo el escenario legible en una prueba automática real. En resumen, Gherkin describe el comportamiento y Cucumber lo une con el código que lo ejecuta.

Es la estructura de tres partes con la que se escribe cada escenario en Gherkin, y sigue la lógica natural de una prueba. Given, que se traduce como «dado», pone el sistema en un estado conocido antes de que empiece la interacción: describe el contexto inicial, como un carrito con cierto subtotal y un cupón válido. When, «cuando», describe la acción o el evento que ocurre, como aplicar el cupón. Y Then, «entonces», especifica el resultado esperado y debe apoyarse en una comprobación que compare lo que realmente pasó con lo que se esperaba, como que el subtotal quede reducido. Las palabras And y But permiten encadenar pasos adicionales del mismo tipo para que el escenario se lea con fluidez. Esta estructura obliga a pensar cada caso como contexto, acción y resultado, que es justamente la anatomía de una buena prueba.

No, funciona por encima de ellas. Cucumber y Gherkin se ocupan de la capa de descripción legible y de conectarla con el código, pero la acción concreta de abrir un navegador, hacer clic o comprobar un resultado la sigue haciendo una herramienta de automatización real. En la práctica, dentro de las definiciones de paso —el código que ejecuta cada línea del escenario— se usa Playwright, Cypress o Selenium para una aplicación web, o llamadas directas a una API si lo que se prueba es un servicio. Es decir, BDD no compite con esas herramientas sino que las envuelve en una capa de lenguaje común. Por eso adoptar BDD implica sumar una capa sobre la automatización que ya se tiene, y esa capa solo vale la pena si aporta la colaboración entre roles que justifica su costo.

Conviene cuando la colaboración entre roles es real: cuando las personas de negocio, desarrollo y QA se sientan a acordar los escenarios antes de programar, cuando el comportamiento del negocio es central y complejo, y cuando esos escenarios van a servir de documentación viva que la gente lee. En esos casos BDD reduce malentendidos y alinea a todo el equipo alrededor de un mismo texto. No conviene cuando solo el equipo técnico escribe y lee los escenarios, cuando se escriben después de programar para «documentar» pruebas ya hechas, o cuando son pruebas puramente técnicas sin ninguna lectura de negocio. En esos casos se paga todo el costo de mantener la capa de Gherkin sin recibir su único beneficio real, y suele ser mejor escribir las pruebas directamente con la herramienta de automatización.

Usar Gherkin como un simple envoltorio de pruebas técnicas que ninguna persona de negocio va a leer jamás. Es el antipatrón más frecuente y el que hace que muchos equipos abandonen BDD decepcionados. Cuando ocurre, el equipo mantiene toda la maquinaria —los escenarios, las definiciones de paso, la traducción entre ambos— pero no obtiene el beneficio que justifica ese trabajo, que es la conversación y el acuerdo entre roles distintos. El síntoma es claro: si al preguntar quién lee los escenarios la respuesta es «solo nosotros, el equipo técnico», entonces la capa de Gherkin está agregando costo sin aportar nada, y casi siempre es mejor escribir las pruebas directamente. BDD es una herramienta para un problema concreto, alinear a personas que hablan idiomas distintos, no un objetivo en sí mismo ni una moda que haya que adoptar.