ES
RU
EN
ZH
FR
DE
PT
AR
HI
BDD en TypeScript: cuando el código habla el lenguaje del negocio
\n\n¿Alguna vez ha traducido un documento de requisitos de varias páginas para darse cuenta de que el cliente quería decir algo completamente diferente? ¿Le resulta familiar la situación en la que un desarrollador y un analista miran la misma tarea pero ven dos aplicaciones diferentes? Si es así, ya está maduro para BDD (Behaviour-Driven Development) — una metodología que borra la frontera entre «quiero» y «hecho».
\n\nHoy hablaremos sobre cómo implementar BDD en TypeScript. Le mostraré cómo convertir aburridas especificaciones en escenarios vivos y ejecutables que tanto un gerente como un desarrollador backend puedan entender. No se trata solo de pruebas — se trata del lenguaje común del equipo.
\n\nPor cierto, si recién está comenzando su camino en TypeScript, le recomiendo echar un vistazo a la base de conocimientos de PythonLib — allí hay excelentes materiales sobre los fundamentos. Y nosotros seguimos adelante.
\n\n¿Qué es BDD y por qué lo necesita?
\n\nBehaviour-Driven Development es una evolución de TDD (Test-Driven Development). Mientras que TDD se enfoca en «cómo» funciona el código (las pruebas se escriben antes de la implementación), BDD responde a la pregunta «qué» debe hacer el sistema desde el punto de vista del usuario.
\n\nLa característica principal de BDD es la sintaxis Gherkin. Es la estructura «Dado — Cuando — Entonces» (Given — When — Then), que se ve así:
\n\nFuncionalidad: Autenticación de usuario\n Como usuario registrado\n Quiero iniciar sesión en el sistema\n Para acceder al panel personal\n\n Escenario: Inicio de sesión exitoso\n Dado un usuario con email "test@example.com" y contraseña "123456"\n Cuando el usuario ingresa datos correctos\n Entonces el sistema lo redirige al panel personal\n¿Está de acuerdo en que esto es más comprensible que «la prueba unitaria verifica que el método login() devuelve true»? Ahí radica la fuerza de BDD: las pruebas en TypeScript se convierten en documentación que cualquier miembro del equipo puede leer.
\n\n¿Cuándo se amortiza BDD?
\n\n- \n
- Lógica de negocio compleja — cuando hay muchas condiciones, cadenas de acciones y escenarios de error en el código. \n
- Equipos distribuidos — analistas en Madrid, desarrolladores en Buenos Aires, testers en Bogotá. BDD es su lenguaje común. \n
- Microservicios — cuando es necesario describir claramente los contratos de interacción entre servicios. \n
Herramientas para BDD en TypeScript
\n\nPara implementar BDD en TypeScript tenemos dos herramientas principales: Cucumber.js (o sus variantes) y Jest con plugins. Analicemos ambos enfoques.
\n\nCucumber.js + TypeScript: el clásico
\n\nCucumber es el estándar de oro de BDD. Lee archivos Gherkin (generalmente con extensión .feature) y ejecuta los steps de código que usted escribe en TypeScript.
Instalación:
\n\nnpm install --save-dev @cucumber/cucumber typescript ts-node\nnpm install --save-dev @types/node\nCreamos el archivo features/login.feature:
Funcionalidad: Inicio de sesión en el sistema\n Como usuario\n Quiero autenticarme\n Para acceder a las funciones\n\n Escenario: Inicio de sesión exitoso con email y contraseña correctos\n Dado que abro la página de inicio de sesión\n Cuando ingreso el email "admin@test.com"\n Y ingreso la contraseña "secret"\n Y hago clic en el botón "Iniciar sesión"\n Entonces veo el mensaje de bienvenida "¡Bienvenido, Admin!"\nAhora escribimos los steps en TypeScript. Creamos features/step_definitions/login.steps.ts:
import { Given, When, Then } from '@cucumber/cucumber';\nimport { expect } from 'chai';\n\n// Simulación simple del estado de la aplicación\nconst appState = {\n currentPage: '',\n loggedInUser: ''\n};\n\nGiven('que abro la página de inicio de sesión', function () {\n appState.currentPage = 'login';\n appState.loggedInUser = '';\n});\n\nWhen('ingreso el email {string}', function (email 
