Debugging real: breakpoints y el método científico

console.log es espiar por la ventana. El debugger es entrar a la casa y congelar el tiempo: pausas el programa en marcha, miras cada variable como está EN ESE INSTANTE, y avanzas paso a paso. Hoy aprendes la herramienta que todo profesional usa a diario —y, más importante, el método para no volver a depurar adivinando.

Congelar el tiempo

El breakpoint: un alto en el camino

Un breakpoint es una marca que le dice al navegador "detente justo aquí y déjame mirar". Hay dos formas de ponerlo:

1. Desde el código, con la palabra debugger. Cuando las DevTools están abiertas, la ejecución se detiene en esa línea:

function calcularTotal(gastos) {
let total = 0;
for (const gasto of gastos) {
  debugger;   // ⏸ el programa se congela aquí en cada vuelta
  total += gasto.valor;
}
return total;
}

2. Desde las DevTools, haciendo clic en el número de línea en la pestaña Sources (Chrome/Edge) o Debugger (Firefox). Es lo mismo, sin tocar el código —el favorito del día a día.

Con el programa congelado: los cuatro botones

Cuando la ejecución se detiene, aparece una botonera de control. Estos son los cuatro movimientos que importan:

▶  Resume (F8)      → sigue corriendo hasta el próximo breakpoint
↷  Step over (F10)  → ejecuta la línea actual y para en la SIGUIENTE
                     (sin entrar dentro de las funciones que llame)
↓  Step into (F11)  → si la línea llama a una función, ENTRA en ella
↑  Step out (⇧F11)  → termina la función actual y vuelve a quien la llamó

Con estos cuatro recorres el programa como una película en cámara lenta con control de avance. Step over es el que más usas: avanzas línea a línea sin perderte dentro de funciones de librerías. Step into cuando sospechas que el bug vive DENTRO de una función tuya.

Las tres ventanas que lo dicen todo

Mientras estás pausado, tres paneles te muestran el estado congelado:

Además, con el programa pausado la consola sí funciona en ese contexto: escribe gasto y presiona Enter para inspeccionarlo, o prueba total + gasto.valor para ver qué daría —sin modificar nada. Es un laboratorio con el tiempo detenido.

Breakpoints condicionales: parar solo cuando importa

Si un bucle corre 10.000 veces y solo falla en la iteración del gasto "Cine", no vas a presionar Resume diez mil veces. Clic derecho en el breakpoint → Add conditional breakpoint → escribe una condición:

// el breakpoint SOLO detiene cuando esto es verdadero:
gasto.nombre === "Cine"

El programa vuela por todas las vueltas y se congela exactamente en la que te interesa. Este truco convierte una depuración de media hora en una de treinta segundos.

Lo que de verdad importa: el método

Las herramientas son inútiles sin un método. Depurar NO es cambiar cosas al azar hasta que "funcione" —eso deja bugs escondidos. Es una investigación con pasos:

Y el truco más viejo y más subestimado: el pato de goma. Explícale el problema en voz alta, línea por línea, a un pato de goma (o a un colega, o al techo). En la mitad de las veces, el bug se te revela solo al forzarte a verbalizar lo que el código REALMENTE hace en vez de lo que crees que hace. No es broma: tiene nombre —rubber duck debugging— y funciona.

Mini-reto

Este se hace en TU navegador, no en un playground: 1) crea un archivo con la función calcularTotal(gastos) de arriba, donde uno de los gastos tenga valor: "25000" (string, el bug); 2) abre DevTools (F12) → Sources, pon un breakpoint dentro del bucle; 3) recorre con Step over mirando el panel Scope cómo total pasa de número a "180002500..." (concatenación de string) en la vuelta traicionera. Ver el bug ocurrir congelado vale más que mil logs.

Qué sigue

Tienes el arsenal completo: leer errores, lanzarlos, tipificarlos, la estrategia de fallar bien, la consola avanzada y el debugger. Momento de usarlo todo junto: el reto del módulo toma "Mi Bolsillo" y lo BLINDA — validaciones con errores propios, redes en los bordes, mensajes de usuario y limpieza garantizada.