Por qué TDD no es una moda pasajera, sino tu nuevo mejor amigo
\n\nImagina: escribes código, todo funciona perfectamente. Ejecutas la aplicación — sin errores. Una semana después agregas una nueva funcionalidad, y... todo se rompe. ¿Te suena familiar? Si alguna vez has pasado horas buscando un error que apareció debido a un cambio accidental en un módulo vecino — este artículo es para ti.
\n\nDesarrollo Guiado por Pruebas (Test-Driven Development, TDD) no es solo una metodología, sino un verdadero salvavidas para el desarrollador. En el mundo de JavaScript, donde el código cambia más rápido que el clima, TDD ayuda a mantenerse a flote. Analicemos cómo funciona y por qué después de TDD ya no podrás escribir código como antes.
\n\n¿Qué es realmente TDD? (Spoiler: no se trata de pruebas)
\n\nMuchos piensan que TDD es simplemente "escribir pruebas antes del código". Pero en realidad es una filosofía de diseño. TDD te obliga a pensar en cómo se usará tu código, antes de escribirlo. Es como un arquitecto que primero dibuja el plano del edificio y luego comienza a construir.
\n\nEl ciclo de TDD consta de tres pasos (a menudo llamado "Red-Green-Refactor"):
\n\n- \n
- Red: Escribe una prueba que fallará a propósito (porque la funcionalidad aún no existe). \n
- Green: Escribe el código mínimo para que la prueba pase. \n
- Refactor: Mejora el código sin cambiar su comportamiento (las pruebas garantizan que no has roto nada). \n
Y sí, este ciclo se repite para cada pequeña unidad de funcionalidad. ¿Suena a ralentización? Quizás. Pero a la larga ahorrarás horas de depuración.
\n\nPor qué JavaScript es ideal para TDD
\n\nJavaScript es un lenguaje dinámico. Esta es su fortaleza y su debilidad. Los errores en tiempo de ejecución son algo común, especialmente en proyectos grandes. TDD transforma JavaScript de una herramienta "flexible pero frágil" en una plataforma confiable.
\n\nAdemás, el ecosistema de JS es rico en herramientas de testing: Jest, Mocha, Chai, Jasmine. Usaremos Jest — es simple, potente y popular. Si aún no conoces Jest, no te preocupes: empezaremos desde lo básico.
\n\nPráctica: escribimos una calculadora con TDD
\n\nLa teoría está bien, pero pasemos al código real. Escribiremos una calculadora simple usando TDD. Es un ejemplo clásico, pero demuestra perfectamente el proceso.
\n\nPaso 1: Configuración del proyecto
\n\nCrea una nueva carpeta e inicializa el proyecto:
\n\nmkdir tdd-calculator\ncd tdd-calculator\nnpm init -y\nnpm install --save-dev jest\n\n\nAgrega el script en package.json:
"scripts": {\n "test": "jest"\n}\n\n\nPaso 2: Rojo — escribimos una prueba para la suma
\n\nCrea el archivo calculator.test.js:
// calculator.test.js\nconst { add } = require('./calculator');\n\ndescribe('Calculator', () => {\n test('adds 2 + 3 to equal 5', () => {\n expect(add(2, 3)).toBe(5);\n });\n});\n\n\nEjecuta la prueba: npm test. Fallará con un error porque la función add no existe. Esto es normal — es la fase roja.
Paso 3: Verde — escribimos el código mínimo
\n\nCrea calculator.js:
// calculator.js\nfunction add(a, b) {\n return a + b;\n}\n\nmodule.exports = { add };\n\n\nEjecuta la prueba de nuevo. ¿Verde? ¡Excelente! Acabamos de pasar la fase verde.
\n\nPaso 4: Refactorización
\n\nEl código es simple, no hay nada que refactorizar. Pero imagina que queremos agregar una validación de tipos. TDD permite hacerlo de forma segura: primero la prueba, luego el código.
\n\n// calculator.test.js\ntest('throws error if arguments are not numbers', () => {\n expect(() => add('2', 3)).toThrow('Arguments must be numbers');\n});\n\n\nAhora modificamos add: