TDD: rojo, verde, refactor

Suena a herejía la primera vez: escribir el test ANTES que el código. Verlo fallar. Y solo entonces escribir lo mínimo para que pase. Se llama TDD —Test-Driven Development— y no es una regla religiosa, es una forma de pensar que te obliga a definir QUÉ quieres antes de decidir CÓMO. Hoy recorres el ciclo completo, en vivo.

Construir con el plano antes que con los ladrillos

El ciclo de tres tiempos

El ciclo en vivo: validarGasto

Construyamos una función de validación con TDD. Empezamos por el rojo: un test para una función que todavía no escribimos.

🔴 Paso 1 — Rojo. El test existe, la función no. Debe fallar:

Ese ✗ (un ReferenceError: validarGasto is not defined) es EXACTAMENTE lo que queremos ver primero. Confirma que el test corre y que aún no hay nada que lo satisfaga. Ahora, el mínimo para el verde.

🟢 Paso 2 — Verde. Escribimos lo mínimo. Y agregamos un test más para empujar la función a crecer:

Todo verde. Fíjate en lo que pasó sin que lo planearas: al escribir los tests de los BORDES primero (cero, negativo, texto), la implementación salió robusta de nacimiento. Los tests te empujaron a considerar los casos que el código "apurado" habría olvidado. Ese es el regalo secreto de TDD: diseña por ti.

🔵 Paso 3 — Refactor. Con todo en verde, puedes mejorar sin miedo. Aquí la función ya es clara, pero imagina que quisieras extraer la regla o renombrar: lo haces, corres los tests, y si siguen verdes, el refactor fue seguro. La red está puesta.

Por qué "el rojo primero" no es capricho

Nota honesta: TDD no es obligatorio ni para todo. Para explorar una idea vaga, a veces codeas primero. Pero para lógica con reglas claras —validaciones, cálculos, transformaciones— empezar por el test es una de las disciplinas que más rápido te hace mejor programador. Pruébalo de verdad antes de opinar.

Mini-reto

Recorre el ciclo tú solo: 1) 🔴 escribe (antes que nada) un test para descuento(precio, porcentaje) que espere descuento(1000, 10) → 900, y míralo fallar; 2) 🟢 escribe el mínimo para pasarlo, y agrega tests para bordes (porcentaje 0 → precio intacto, 100 → 0); 3) 🔵 si el cálculo quedó enredado, refactóralo y confirma que sigue verde. Haz al menos una vuelta completa sintiendo cada color.

Qué sigue

Testear funciones puras es el paraíso: entra X, sale Y. Pero el código real habla con el mundo —pide datos a un servidor, lee la hora, guarda en localStorage— y eso es lento e impredecible. La última lección técnica resuelve ese problema con mocks y spies: dobles de acción para tus tests. Y por fin cobra sentido el "bus de mentiras" que te prometí en el módulo 13.