Cuando un proyecto web pasa de ser una página estática a una aplicación interactiva, JavaScript es el motor que impulsa esa transformación. Sin embargo, también es la fuente más común de errores difíciles de rastrear. Saber utilizar las herramientas del navegador para localizar y entender esos errores marca la diferencia entre perder horas revisando código a ciegas y resolver problemas con precisión quirúrgica.
¿Cómo identificar un bug en una operación matemática con JavaScript?
El ejercicio parte de un proyecto público creado por el equipo de Google Chrome, disponible en la sección de recursos. Se trata de una aplicación sencilla con dos campos de entrada numérica y un botón que debería sumar ambos valores [00:42].
Al ingresar 10 en el primer campo y 20 en el segundo, el resultado esperado es 30. Sin embargo, la aplicación devuelve 1020 [01:07]. Este tipo de error es más frecuente de lo que parece y puede ocurrir en escenarios reales como un e-commerce, donde los productos se agregan al carrito y la suma total muestra cantidades incorrectas [01:20].
Antes de buscar la solución, es importante razonar sobre el flujo del problema:
- El botón actúa como un trigger, es decir, el accionable que dispara una función al hacer clic.
- Esa función debe tomar los valores de los inputs como variables.
- Con esos valores debe ejecutar la operación matemática.
¿Qué es un break point y cómo se activa desde Dev Tools?
Un break point es un punto de pausa que se inserta en el código de JavaScript para detener la ejecución y examinar el estado de las variables en ese momento exacto [04:25]. En lugar de abrir directamente el archivo JS, se puede llegar al código relevante a través de la pestaña Sources del inspector de elementos.
¿Cómo usar event listeners para encontrar la función correcta?
Cuando un botón dispara una acción, se registra un event listener [02:42]. Para localizarlo:
- Selecciona el botón en el inspector.
- Busca la sección de event listeners.
- Filtra por la categoría mouse y específicamente por el evento clic [03:05].
Al hacer clic en el botón con esta configuración activa, Dev Tools genera automáticamente un break point dentro de la función onclick, exactamente donde el trigger se dispara [03:30].
¿Cómo avanzar paso a paso por el código?
Una vez posicionado en el break point, aparecen botones de navegación que permiten avanzar por la lógica del código de forma controlada [04:40]. La ejecución no avanza de forma lineal, línea por línea, sino que sigue el flujo real del programa:
- Desde la línea 15, un if statement valida una condición que debe ser verdadera para continuar [04:55].
- La función
getNumberOne obtiene el valor del primer input [05:20].
- La función
getNumberTwo hace lo mismo con el segundo campo [05:50].
- Si la validación no se cumple, el bloque
else dispara la función de actualizar los labels [06:20].
¿Qué revela el scope sobre los valores de las variables?
Al llegar a la línea 32, la sección de Scope en Dev Tools muestra los valores actuales de las variables locales y globales [07:15]. En este punto se puede observar:
- El valor del primer número: 10.
- El valor del segundo número: 20.
- El valor de la variable suma: 1020.
El scope es el contexto donde viven las variables durante la ejecución del código. Revisarlo permite confirmar que los valores se extrajeron correctamente de los inputs, pero que la operación de suma no se comporta como se esperaba [07:30].
Todo el recorrido demuestra cómo Dev Tools permite trazar el camino completo de una función: desde el clic del usuario, pasando por la extracción de valores, hasta la generación del resultado. A este punto, el bug ya es visible en los datos del scope, aunque la corrección se abordará en la siguiente sesión.
Si ya replicaste el ejercicio y notaste por qué la suma devuelve 1020 en lugar de 30, comparte tu teoría en los comentarios.
