Si programas, ya has oído mil veces que necesitas escribir pruebas unitarias —y quizá hayas sentido esa mezcla de culpa y pereza. Esta guía es para quienes nunca han escrito una: sin jerga, sin dogmas, solo lo esencial para entender por qué vale la pena probar y salir de aquí con el primer test ejecutándose.
Qué es (y qué no es) una prueba unitaria
Una prueba unitaria es un pequeño fragmento de código que verifica automáticamente si una parte pequeña de tu programa hace lo que debería. "Pequeña" es la palabra clave: normalmente se trata de una función o un método, aislados del resto —sin base de datos, sin red y sin interfaz.
Lo que no es: no consiste en abrir la aplicación y hacer clic para comprobar si funciona (eso es una prueba manual), ni en probar el sistema completo de principio a fin (ese es otro tipo de prueba). La prueba unitaria apunta al ladrillo, no al edificio.
Por qué escribir pruebas si el código ya funciona
Es la pregunta honesta de toda persona que está empezando. La respuesta: las pruebas no sirven para demostrar que el código funciona hoy, sino para avisarte cuando deje de funcionar mañana.
Piensa en ellas como una red de seguridad. Sin red, cada cambio en el código es una apuesta: ¿habré roto algo en otra parte? Con una red, haces el cambio, ejecutas las pruebas y lo sabes en segundos. Eso es lo que te da valor para refactorizar y velocidad para crecer sin miedo. El tiempo que "pierdes" escribiendo la prueba lo recuperas con intereses la primera vez que te salva de un bug en producción.
Anatomía de una prueba: preparar, actuar y verificar
Casi todas las pruebas siguen tres pasos, un patrón fácil de recordar:
- Preparar: construye el escenario —los datos de entrada y el objeto que vas a probar.
- Actuar: llama a la función que quieres verificar.
- Verificar: comprueba si el resultado era el esperado.
Si puedes describir tu prueba con estas tres frases antes de escribirla, ya habrás hecho la mitad del trabajo.
Tu primera prueba, en la práctica
Imagina una función sencilla que suma dos números. La prueba pregunta: "si le paso 2 y 3, ¿devuelve 5?". Preparas los valores (2 y 3), actúas (llamas a la función) y verificas (¿el resultado es 5?). Si lo es, la prueba pasa; si no, falla y señala exactamente dónde está el problema.
El detalle liberador: la primera prueba casi siempre parece demasiado tonta, porque comprueba algo obvio. No pasa nada. El objetivo es aprender el ritmo —preparar, actuar y verificar— con algo sencillo para después aplicarlo a código real.
Qué probar primero (y qué dejar para después)
No necesitas (ni debes) probarlo todo desde el principio. Empieza por lo que más duele cuando falla:
- Reglas de negocio: cálculos, validaciones y decisiones. Es donde los bugs pueden salir más caros.
- Casos límite: una lista vacía, un valor cero o una entrada inesperada. Es donde el código suele tropezar.
Y deja para después el código trivial (un getter que solo devuelve un valor no necesita una prueba) y las partes demasiado ligadas a una base de datos o a la red: necesitan otros tipos de pruebas, no pruebas unitarias.
Errores comunes al empezar
Dos tropiezos clásicos que puedes evitar desde el principio:
- Probar demasiadas cosas de una vez. Una prueba debe verificar UNA sola cosa. Si falla, quieres saber de inmediato qué se rompió, no buscar entre diez verificaciones.
- Probar el "cómo" en lugar del "qué". Verifica el resultado, no los pasos internos. Si atas la prueba a detalles de implementación, cualquier refactorización inofensiva la romperá; entonces la prueba se convierte en un estorbo, no en una red de seguridad.
Al final, una prueba unitaria tiene menos que ver con "garantizar la calidad" en abstracto y más con algo concreto: dormir tranquilo después del deploy. Escribe la primera hoy, aunque parezca tonta. La segunda saldrá de forma más natural y, en poco tiempo, modificar código sin una red de seguridad te parecerá lo que siempre fue: saltar sin paracaídas.
