El Desarrollo Dirigido por el Comportamiento (BDD) ha cambiado fundamentalmente la forma en que los equipos piensan sobre la calidad del software al hacer que las pruebas sean legibles para todos. Utilizar Cucumber para las pruebas BDD es una habilidad que tiende un puente entre los requisitos comerciales y la implementación técnica, creando documentación viva que realmente se ejecuta. Si has tenido problemas con casos de prueba que quedan desactualizados en el momento en que se escriben, esta guía te mostrará una forma mejor.
¿Qué son Cucumber y BDD?
Cucumber es una herramienta de código abierto que ejecuta pruebas automatizadas escritas en lenguaje natural. Implementa el Desarrollo Dirigido por el Comportamiento (BDD), una metodología en la que desarrolladores, testers y partes interesadas del negocio colaboran para definir el comportamiento del software utilizando ejemplos concretos.
BDD se centra en responder una pregunta: "¿Qué debería hacer el sistema?" en lugar de "¿Cómo deberíamos probarlo?". El resultado es un lenguaje compartido que elimina los malentendidos y crea pruebas que sirven tanto como especificaciones como validación ejecutable.
Cucumber lee archivos .feature que contienen escenarios escritos en sintaxis Gherkin y los ejecuta contra las definiciones de pasos (código que realiza la automatización real). Esta separación significa que las partes interesadas del negocio pueden revisar los escenarios de prueba sin leer código, mientras que los desarrolladores implementan los detalles técnicos por separado.
Instalación de Cucumber para JavaScript
Configurar Cucumber en un proyecto Node.js requiere solo unos pocos comandos:
Prerrequisitos:
- Node.js
- NPM
- Un proyecto API que tenga una función de inicio de sesión que probaremos (Este tutorial solo cubrirá la instalación de Cucumber y las pruebas Gherkin).
# Crear un nuevo directorio de proyecto
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo
# Inicializar npm
npm init -y
# Instalar Cucumber y dependencias de prueba
npm install --save-dev @cucumber/cucumber chai axios
Tu archivo package.json debería incluir un script de prueba:
{
"scripts": {
"test": "cucumber-js"
}
}
Crea esta estructura de directorios:
project/
├── features/
│ └── user-management.feature
├── step-definitions/
│ └── user-steps.js
├── package.json
└── cucumber.json
Guía Práctica: Escribiendo tu Primera Prueba BDD
Construyamos una prueba para una API de gestión de usuarios para demostrar Cómo Usar Cucumber para Pruebas BDD en la práctica.
Paso 1: Escribe el archivo Feature
Crea features/user-management.feature:
Característica: API de gestión de usuarios
Como cliente de API
Quiero gestionar usuarios
Para poder integrar la funcionalidad de usuario en mi aplicación
Escenario: Crear un nuevo usuario con éxito
Dado que tengo una carga útil de usuario válida
Cuando envío una solicitud POST a "/api/users"
Entonces el estado de la respuesta debería ser 201
Y la respuesta debería contener un ID de usuario
Escenario: Intentar crear un usuario con un correo electrónico inválido
Dado que tengo una carga útil de usuario con un correo electrónico inválido
Cuando envío una solicitud POST a "/api/users"
Entonces el estado de la respuesta debería ser 400
Y la respuesta debería contener "Formato de correo electrónico inválido"
Paso 2: Implementar las definiciones de pasos
Crea step-definitions/user-steps.js:
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
const axios = require('axios');
let requestPayload;
let response;
Given('I have a valid user payload', function() {
requestPayload = {
name: 'Test User',
email: 'test@example.com',
password: 'ValidPass123'
};
});
Given('I have a user payload with invalid email', function() {
requestPayload = {
name: 'Test User',
email: 'invalid-email',
password: 'ValidPass123'
};
});
When('I send a POST request to {string}', async function(endpoint) {
try {
response = await axios.post(`http://localhost:3000${endpoint}`, requestPayload);
} catch (error) {
response = error.response;
}
});
Then('the response status should be {int}', function(statusCode) {
expect(response.status).to.equal(statusCode);
});
Then('the response should contain a user ID', function() {
expect(response.data).to.have.property('userId');
expect(response.data.userId).to.match(/^[0-9a-fA-F]{24}$/);
});
Then('the response should contain {string}', function(message) {
expect(response.data.message).to.include(message);
});
Paso 3: Edita el archivo cucumber.json
Crea un archivo "cucumber.json" en el directorio raíz de tu proyecto y añade el siguiente código:
{
"default": {
"formatOptions": {
"snippetInterface": "synchronous"
}
}
}Paso 4: Ejecuta las pruebas
Ejecuta tus pruebas con:
npm test
Cucumber mostrará resultados detallados que indican qué pasos pasaron, están indefinidos o fallaron.
Reglas para escribir buenos escenarios BDD
Aprender Cómo Usar Cucumber para Pruebas BDD de forma efectiva requiere seguir estas reglas probadas:
1. Estructura Dado-Cuando-Entonces (Given-When-Then)
Cada escenario debe tener estas tres partes en orden:
- Dado: Establece las precondiciones
- Cuando: Describe la acción
- Entonces: Valida el resultado
2. Escribir de forma declarativa, no imperativa
Mal:
Dado que abro el navegador
Y navego a "/login"
Y escribo "test@example.com" en el campo de correo electrónico
Y escribo "password" en el campo de contraseña
Y hago clic en el botón de iniciar sesión
Bien:
Dado que estoy en la página de inicio de sesión
Cuando inicio sesión con credenciales válidas
Entonces debería ver el panel de control
Concéntrate en lo que estás probando, no en cómo lo haces.
3. Un escenario, un propósito
Cada escenario debe probar un solo comportamiento. Los escenarios combinados ocultan fallos y dificultan la depuración.
4. Utiliza lenguaje empresarial
Escribe escenarios que los stakeholders del negocio puedan entender. Evita la jerga técnica y los detalles de implementación.
5. Haz que los escenarios sean independientes
Los escenarios no deben depender unos de otros. Cada uno debe configurar sus propios datos y limpiar después.
Características Avanzadas de Cucumber: Tablas de Datos y Esquemas de Escenarios
Tablas de Datos para Entradas Complejas
Cuando necesites probar con múltiples puntos de datos, usa tablas:
Escenario: Crear usuarios con diferentes roles
Dado que tengo los siguientes datos de usuario:
| nombre | correo electrónico | rol |
| Alice | alice@example.com | administrador |
| Bob | bob@example.com | usuario |
Cuando envío una solicitud POST a "/api/users"
Entonces todos los usuarios deberían ser creados exitosamente
Definición de paso:
Given('I have the following user data:', function(dataTable) {
requestPayload = dataTable.hashes();
});
Esquemas de Escenarios para Pruebas Orientadas a Datos
Cuando quieras ejecutar el mismo escenario con datos diferentes, usa esquemas:
Esquema de Escenario: Inicio de sesión con varias credenciales
Dado que estoy en la página de inicio de sesión
Cuando introduzco "<email>" y "<password>"
Entonces debería ver "<resultado>"
Ejemplos:
| email | password | resultado |
| test@example.com | validPass | Panel de control |
| test@example.com | wrongPass | Contraseña inválida |
| invalid@email.com | validPass | Correo inválido |
Esto crea automáticamente tres escenarios de prueba separados.
Organización de pruebas con etiquetas
Las etiquetas te ayudan a categorizar y filtrar escenarios:
@smoke @regression
Escenario: Inicio de sesión de usuario
Dado que estoy en la página de inicio de sesión
Cuando inicio sesión con credenciales válidas
Entonces debería ver el panel de control
@api @critical
Escenario: Comprobación de salud de la API
Dado que la API está en funcionamiento
Cuando solicito "/health"
Entonces el estado de la respuesta debería ser 200
Ejecuta solo etiquetas específicas:
npm test -- --tags "@smoke"
Cómo Apidog ayuda con las pruebas de API en flujos de trabajo BDD
Mientras que Cucumber sobresale en la definición del comportamiento, Apidog automatiza el trabajo pesado de la creación y ejecución de pruebas de API, haciendo que Cucumber para las pruebas BDD sea mucho más eficiente.
Generación de Casos de Prueba de API impulsada por IA
En lugar de escribir manualmente las definiciones de pasos para las llamadas a la API, Apidog las genera a partir de tu especificación OpenAPI usando IA:
# Tu especificación de API
paths:
/api/users:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
name: string
email: string
responses:
'201':
description: Usuario creado
Apidog crea automáticamente escenarios listos para la prueba:
- Prueba positiva: Carga útil válida → estado 201
- Prueba negativa: Correo electrónico inválido → estado 400
- Prueba de límite: Campo requerido faltante → estado 400
Preguntas Frecuentes
P1: ¿Necesito saber programar para escribir pruebas con Cucumber?
Resp: Escribir escenarios Gherkin no requiere codificación, solo un pensamiento claro sobre el comportamiento. Sin embargo, la implementación de las definiciones de pasos requiere conocimientos de JavaScript (u otro lenguaje). Herramientas como Apidog reducen esta carga al generar automáticamente el código de definición de pasos.
P2: ¿En qué se diferencia Cucumber de los frameworks de prueba tradicionales?
Resp: Los frameworks tradicionales (Jest, Mocha) se centran en la implementación técnica. Cucumber se centra en el comportamiento empresarial. El mismo escenario de Cucumber puede impulsar pruebas de UI web (Selenium), pruebas de API (Axios) o pruebas móviles (Appium) sin cambiar el texto Gherkin.
P3: ¿Puede Cucumber reemplazar las herramientas de prueba de API?
Resp: Cucumber proporciona la estructura de la prueba, pero aún necesitas herramientas para ejecutar llamadas a la API (Axios, Supertest) y validar las respuestas. Apidog complementa a Cucumber al manejar la capa de ejecución de la API, mientras que Cucumber gestiona el flujo de trabajo BDD.
P4: ¿Qué hace que un escenario de Cucumber sea bueno?
Resp: Los buenos escenarios son independientes, usan lenguaje de negocios, siguen la estructura Dado-Cuando-Entonces y prueban un comportamiento cada uno. Deben ser legibles por stakeholders no técnicos y centrarse en lo que hace el sistema, no en cómo lo hace.
P5: ¿Cómo maneja Apidog la autenticación en las pruebas BDD?
Resp: Apidog gestiona los tokens de autenticación automáticamente. Puedes definir pasos "Dado que estoy autenticado" que utilizan la gestión de credenciales de Apidog para recuperar tokens válidos, eliminando el manejo manual de tokens en tus definiciones de pasos.
Conclusión
Usar Cucumber para las pruebas BDD transforma eficazmente tu proceso de desarrollo al crear una comprensión compartida entre los equipos técnicos y de negocios. La sintaxis de Gherkin fuerza la claridad, mientras que la separación de escenarios y definiciones de pasos mantiene las pruebas fáciles de mantener a medida que tu aplicación evoluciona.
El verdadero poder proviene de integrar Cucumber con herramientas de automatización modernas. Apidog elimina el tedioso trabajo manual de escribir código de prueba de API, permitiéndote concentrarte en definir comportamientos significativos mientras maneja la ejecución. Esta combinación ofrece lo mejor de ambos mundos: especificaciones legibles por humanos que sirven como documentación viva y pruebas automatizadas robustas que se ejecutan continuamente.
Empieza poco a poco. Elige un punto final de API. Escribe tres escenarios: éxito, fallo y caso límite. Implementa las definiciones de pasos. Ejecútalas. Muestra los resultados a tu product owner. Una vez que vean los requisitos de negocio ejecutados como pruebas, tendrás el apoyo para expandir BDD en todo tu proyecto. Es entonces cuando usar Cucumber para las pruebas BDD deja de ser una práctica técnica y se convierte en un movimiento de calidad en todo el equipo.