Integrar Behavior Driven Development en Cypress con Cucumber y Gherkin te permite escribir pruebas automatizadas legibles para cualquier persona del equipo, no solo para quienes programan. Aquí aprenderás a configurar los plugins necesarios, crear features, definir steps dinámicos y ajustar el patrón de búsqueda de pruebas en Cypress.

¿Qué necesitas instalar para usar Cucumber en Cypress?

Cypress no soporta Gherkin de forma nativa, así que necesitas dos librerías que actúen como puente entre los archivos .feature y el motor de pruebas.

• cypress-webpack-preprocessor: compila y transpila los archivos para que Cypress los entienda.
• @badeball/cypress-cucumber-preprocessor: interpreta la sintaxis Gherkin y la convierte en pruebas ejecutables.

¿Qué es un preprocesador en Cypress? Es una capa que transforma archivos no nativos, como los .feature de Cucumber, en código que Cypress puede ejecutar como prueba. Sin él, Cypress ignoraría esos archivos.

Esto lo viste alrededor del [2:10] cuando se explica por qué hay que instalar ambas dependencias antes de tocar la configuración.

¿Cómo configurar el archivo cypress.config para Cucumber?

La configuración cambia bastante respecto a un proyecto Cypress estándar. Vas a mover lógica al setupNodeEvents y a cambiar el specPattern.

¿Qué hace el setupNodeEvents con el preprocesador?

Dentro de setupNodeEvents defines una función asíncrona que registra el preprocesador de Cucumber y lo conecta con Webpack. Importas addCucumberPreprocessor y le pasas la configuración que la propia documentación del plugin te ofrece. Al final, esa función debe retornar el objeto config para que Cypress reciba los cambios.

La idea es sencilla: cuando Cypress detecta un archivo .feature, lo manda a Webpack, que lo transpila usando el plugin de Cucumber.

¿Por qué cambiar el specPattern?

Por defecto, Cypress busca archivos .cy.js o .cy.ts. Al cambiar el specPattern a algo como **/*.feature, le dices que ahora tus pruebas viven en archivos feature escritos en Gherkin. Por eso, al reiniciar Cypress en el [9:30] aproximadamente, ya no aparecen las pruebas anteriores: el patrón cambió.

¿Cómo se estructura un feature y sus step definitions?

La convención del plugin es estricta: el archivo .feature y el archivo .js con los steps deben llamarse igual y vivir juntos.

Una estructura recomendada se ve así:

• Carpeta features/ dentro de e2e/.
• Subcarpeta login/ para evitar conflictos de nombres.
• Archivos login.feature y login.js dentro de esa subcarpeta.

El .feature contiene el escenario en Gherkin con la estructura Given, When, Then. El .js importa esas mismas funciones desde el preprocesador y las implementa.

¿Qué diferencia hay entre Given, When y Then? Given describe las precondiciones, When representa la acción que dispara el comportamiento y Then es el criterio de aceptación que valida si la prueba pasó o falló.

¿Cómo crear steps dinámicos con parámetros?

Aquí está una de las grandes ventajas de Gherkin: puedes pasar datos directamente desde el escenario al step.

Cuando escribes algo como When I login with "username" and "password", el preprocesador detecta lo que está entre comillas y lo convierte en parámetros que recibes en la función. En el código de implementación, esos valores llegan como argumentos:

js When('I login with {string} and {string}', (username, password) => { loginPage.login(username, password) })

Esto significa que un mismo step sirve para múltiples escenarios con credenciales distintas. Si mañana tu product owner quiere probar con otro usuario, solo edita el .feature sin tocar el código JavaScript. Este detalle se explica cerca del [7:45].

¿Qué editor facilita escribir step definitions?

En el video se usa WebStorm porque detecta automáticamente si un step ya está definido y permite generar el step definition con un clic. Si trabajas en VS Code, busca extensiones equivalentes para Cucumber. No es obligatorio: puedes escribir los steps manualmente siempre que el texto coincida exactamente con el del feature.

¿Qué ventajas reales tiene este enfoque BDD?

Cuando ejecutas la prueba en Cypress, ves cada paso descrito en lenguaje natural: Given I am in the login page, When I login with valid credentials, Then I should validate that I am logged in. Eso cambia la experiencia de leer pruebas.

• Cualquier persona del equipo puede leer y entender el comportamiento esperado.
• Los features pueden modificarse sin tocar código JavaScript.
• Los steps dinámicos reducen duplicación.
• El reporte visual conecta directamente con la historia de usuario.

Si metes credenciales inválidas a propósito, la prueba falla y, con retries activado, Cypress reintenta antes de marcarla como rota. Eso lo demuestra el ejercicio final cerca del [11:20].

En la siguiente clase se aborda shared step definitions, una técnica para reutilizar pasos entre varios features. ¿Tú qué prefieres: el enfoque clásico con .cy.js o este flujo BDD con Gherkin? Cuéntalo en los comentarios.