Un buen test: AAA y el arte de romper el código

Escribir un test que pase es fácil. Escribir un test que VALGA la pena es otra cosa: uno que sea claro cuando falle, que pruebe una sola idea, y que ataque los casos que rompen el código —el vacío, el negativo, el null. Hoy aprendes a pensar como quien quiere QUEBRAR tu función, que es la única forma de asegurarla.

El testeador piensa distinto

AAA: la anatomía de un buen test

Todo test claro tiene tres actos, aunque no siempre los marques. Se llama patrón AAA: Arrange (preparar), Act (actuar), Assert (afirmar):

Los tres actos ordenan tu pensamiento: primero montas el escenario, luego disparas UNA acción, luego verificas UNA cosa. Separarlos —aunque sea con líneas en blanco— hace que cualquiera lea el test en cinco segundos y entienda qué se está probando. Un test desordenado es tan malo como código desordenado.

Una idea por test, con nombre honesto

Un buen nombre completa la frase "la función debería...": "...devolver 0 si no hay gastos", "...lanzar si el valor es negativo". Si no puedes nombrar qué prueba un test, probablemente prueba demasiado.

La caza de casos límite

Aquí está el oro. El camino feliz casi nunca tiene bugs; los bugs viven en los BORDES. Para cada función, pregúntate por los extremos:

El test de la lista vacía es el héroe silencioso: reduce SIN valor inicial lanza sobre un array vacío —un bug que el camino feliz jamás revela, pero que en producción explota el día que un usuario nuevo no tiene gastos. La checklist mental de bordes que debes correr para cada función:

Prueba el QUÉ, no el CÓMO

Un test frágil se aferra a los detalles internos y se rompe cada vez que refactorizas, aunque el comportamiento sea idéntico. Testea la PROMESA pública de la función (entrada → salida, o que lance), no sus pasos internos. Así, si mañana cambias un for por un reduce, tus tests siguen verdes porque el resultado no cambió —y esa es justo la libertad que los tests prometen: refactorizar sin miedo.

Mini-reto

Piensa como rompedor: 1) escribe maximoGasto(gastos) que devuelva el gasto de mayor valor; 2) con el mini-runner de arriba, escríbele tests para el camino feliz Y para tres bordes: lista de un elemento, lista vacía (¿qué DEBERÍA devolver? decídelo tú y testéalo), y valores iguales; 3) haz que al menos un borde falle, arréglala, y míralo pasar. Diseñar qué hace la función en el borde ES diseñar la función.

Qué sigue

Hasta ahora escribiste el código y LUEGO el test. La próxima lección invierte el orden y suena a herejía: escribir el test PRIMERO, verlo fallar en rojo, y recién entonces escribir el código para ponerlo verde. Se llama TDD y, bien usado, cambia cómo diseñas. Con el ciclo corriendo, en vivo, en el playground.