ES
RU
EN
ZH
FR
DE
PT
AR
HI
¿Cómo explicarle a un programador que un bug no es "no funciona"?
\n¿Alguna vez has recibido una tarea como: "Haz que el botón funcione correctamente"? ¿O, peor aún, escribiste código, las pruebas están en verde, y el cliente dice: "Bueno, esto no es lo que pedí"? ¿Te suena familiar? Bienvenido al mundo donde BDD (Behaviour-Driven Development) en JavaScript se convierte en un salvavidas.
\nBDD no es solo otra abreviatura de moda. Es un enfoque que obliga a desarrolladores, testers y analistas de negocio a hablar el mismo idioma. En español, vivo, sin "metodologías" ni "paradigmas arquitectónicos". Hoy analizaremos cómo implementar BDD en un proyecto JavaScript, escribiremos pruebas reales y entenderemos por qué esto hace que el código sea más limpio y la vida más fácil.
\n\n\n\n
¿Qué es BDD y en qué se diferencia de TDD?
\nAclaremos las cosas de inmediato. BDD (Behaviour-Driven Development) es una evolución de TDD (Test-Driven Development). Si TDD dice: "Primero escribe la prueba, luego el código", BDD añade: "Pero la prueba debe ser comprensible para la abuela inversora".
\nLa idea clave de BDD: probamos el comportamiento del sistema, no su estructura interna. No preguntamos: "¿La función devuelve true?". Preguntamos: "¿Puede el usuario agregar un producto al carrito y ver el total del pedido?". La diferencia es enorme.
\nPara BDD en JavaScript existe un lenguaje especial: Gherkin. Es un pseudo-inglés (o pseudo-español) que parece un manual de instrucciones de Lego:
\n\nFuncionalidad: Carrito de compras\n Como usuario registrado\n Quiero agregar productos al carrito\n Para ver el costo total\n\n Escenario: Agregar un producto\n Dado que el usuario está autenticado\n Cuando agrega el producto "Portátil" al carrito\n Entonces en el carrito se muestra 1 producto\n Y el costo total es igual a 99900 pesos\n¿Estás de acuerdo en que se lee como un requisito de negocio, no como código? Y esa es la principal característica de BDD.
\n\n\n\n
Herramientas para BDD en JavaScript
\nPara practicar behaviour-driven development en JavaScript, necesitas las herramientas adecuadas. Aquí están los tres pilares sobre los que se sostiene todo:
\n\n- \n
- Cucumber.js — el framework más popular para BDD. Analiza escenarios Gherkin y los vincula con el código. \n
- Jest + Jest-Cucumber — si ya usas Jest, esta es la opción ideal. Sin magia, solo integración limpia. \n
- Mocha + Chai + Gherkin — para aquellos a los que les gusta armar el rompecabezas manualmente. Flexible, pero más código. \n
Usaremos Cucumber.js porque es el estándar de la industria. La instalación es simple:
\n\nnpm install @cucumber/cucumber --save-dev\nDespués de esto, creamos la carpeta features/ — allí vivirán nuestros archivos .feature. Y en la carpeta step_definitions/ — el código que da vida a los escenarios.
\n\n
Escribimos la primera prueba BDD: autenticación de usuario
\nImaginemos que estamos haciendo una tienda en línea. Lo primero que hay que probar es el inicio de sesión. Creamos el archivo features/login.feature:
# language: es\nFuncionalidad: Autenticación de usuario\n Como visitante del sitio\n Quiero iniciar sesión en mi cuenta personal\n Para gestionar mis pedidos\n\n Escenario: Inicio de sesión exitoso con datos correctos\n Dado que estoy en la página de inicio de sesión\n Cuando ingreso el email "user@example.com" y la contraseña "123456"\n Y hago clic en el botón "Iniciar sesión"\n Entonces veo el saludo "¡Bienvenido, Iván!"\nAhora necesitamos escribir los pasos (steps) — código en JavaScript que ejecutará estas acciones. Creamos step_definitions/login.steps.js:
const { Given, When, Then } = require('@cucumber/cucumber');\nconst { expect } = require('chai');\n\n// Estado de la aplicación (simulación)\nlet currentPage = '';\nlet userEmail = 
