Software Crafters® 2026 | Creado con 🖤 para elevar el nivel de la conversación sobre programación en español | Legal
Te voy a contar la forma de prevenir bugs más barata que existe.
Y que casi nadie aplica.
Te lo digo en serio, pocas cosas hay más eficaces para evitar errores en el código.
Pero bueno, la mayoría leerá este post y seguirá igual.
Mira.
Un test que siempre pasa es peor que no tener test.
La razón es muy simple.
Te da falsa sensación de seguridad y esconde bugs en lugar de exponerlos.
Te cuento un ejemplo.
Hace unos días estaba en code review con un dev de mi equipo y me paré en un test verde.
Le pedí que hiciera mutation testing, que básicamente es romper el código a propósito para probar el test.
Es hacerle un test al test.
Cambió el return por otro valor, comentó una línea, hizo lo que le pareció.
El test seguía pasando. Básicamente no probaba nada.
Eso, multiplicado por toda una suite, es lo que muchos equipos tienen ahora mismo en su CI. Cientos de tests verdes. 80, 90% de cobertura. Y bugs en producción todas las semanas.
Por eso es fundamental el paso rojo en TDD. Es el que prueba que tu test existe para algo.
Tienes que ver el test fallar.
Ese fallo es la evidencia. Cuando luego se pone verde, sabes que ha sido porque la implementación es válida. No por suerte. No por un test mal configurado. No por un falso positivo.
Sin rojo, no hay confianza en lo que escribes.
Y es tentador saltárselo.
"Sé que mi código va a funcionar, ¿para qué verlo fallar?"
"Es más rápido implementar y ver el verde directamente."
Pero saltarte el rojo es como instalar una alarma de incendios que nunca suena. No te enteras de que algo va mal hasta que ya es tarde.
Ver fallar el test es la prevención de bugs más barata y más rápida que vas a encontrar.
Y la excusa de que los tests te los hace la IA tampoco vale. Con los agentes funciona igual, que vea primero el test fallar, es la mejor manera de mantenerlo bajo control.
¿Quiéres leer más artículos como éste? Pues suscríbete a la newsletter