Definición
Un test unitario es un trozo de código que ejecuta una pieza pequeña de tu programa —normalmente una función— con unas entradas concretas y comprueba que devuelve lo que debe.
"Unitario" significa aislado: prueba esa función sola, sin base de datos, sin red, sin depender de otras partes. Por eso es rápido: cientos de tests se ejecutan en segundos.
Su verdadero valor no está en encontrar errores nuevos —para eso son regulares—. Está en avisarte cuando rompes algo que ya funcionaba. Es una red de seguridad para poder cambiar el código sin miedo.
Los tipos de prueba
Se suele hablar de una pirámide, y el orden importa:
Unitarios (la base, muchos). Una función aislada. Milisegundos cada uno.
De integración (menos). Varias piezas juntas: la función que guarda un pedido contra una base de datos de prueba de verdad. Más lentos y más realistas.
De extremo a extremo (pocos). El sistema entero desde el navegador, como lo usaría una persona. Lentos, frágiles y los que más confianza dan cuando pasan.
La forma de la pirámide es una recomendación de coste: muchos rápidos abajo, pocos lentos arriba. El error clásico es la pirámide invertida — todo probado desde el navegador, y una suite que tarda cuarenta minutos y falla sola una de cada tres veces.
Qué probar y qué no
Merece la pena probar:
- Lógica de negocio con reglas: cálculo de márgenes, aplicación de descuentos, prorrateos, impuestos.
- Funciones puras: entra un dato, sale otro, sin efectos externos. Son las más fáciles y las más rentables.
- Casos límite: cero, negativo, vacío, nulo, el máximo.
- Todo error que te haya mordido una vez. Cuando arregles un fallo, escribe el test que lo habría cazado. Así no vuelve.
No merece la pena:
- Código que solo llama a otra cosa sin decidir nada.
- La configuración.
- Probar que el lenguaje o la librería hacen su trabajo.
- Interfaz que cambia cada semana.
Ejemplo práctico
Voy a ser sincero: en mis proyectos no hay una suite de tests unitarios formal. Y donde sí escribí pruebas fue exactamente donde la teoría dice que hay que escribirlas — cuando algo se rompió tres veces seguidas.
En el panel de AEWorks, borrar un proyecto fallaba por restricciones de clave foránea. Lo arreglé. Volvió a fallar al añadir otra tabla relacionada. Lo arreglé otra vez. Y volvió a fallar una tercera.
El problema era el planteamiento: cada vez que aparecía una tabla nueva que apuntaba a proyectos, había que acordarse de tocar la función de borrado. Confiar en la memoria no escala.
La solución fue una prueba que no comprueba un caso, comprueba la regla: lee del propio esquema de la base qué tablas apuntan a proyectos, cuelga una fila de cada una de un proyecto de prueba, y lo borra. Si aparece una tabla nueva y nadie actualizó el borrado, la prueba falla sola.
Esa prueba encontró inmediatamente una tabla que se me había pasado. Es el mejor argumento a favor de las pruebas que puedo dar: no me dijo que algo estaba mal, me dijo qué había olvidado.
Errores comunes
- Perseguir el 100 % de cobertura. La cobertura mide qué líneas se ejecutaron, no si las comprobaciones tienen sentido. Se puede llegar al 100 % con tests que no verifican nada.
- Tests que dependen unos de otros. Si el orden importa, al primer fallo caen todos y no sabes cuál era el problema.
- Probar la implementación en vez del comportamiento. Si al reordenar el código por dentro se rompen veinte tests sin que cambie lo que hace, esos tests estorban.
- Tests lentos. Si la suite tarda diez minutos, nadie la ejecuta antes de subir código. La velocidad es una característica.
- Tests inestables. Uno que falla una de cada cinco veces sin motivo enseña al equipo a ignorar los fallos. Un test poco fiable es peor que ninguno.
- Escribirlos al final. Se escriben mientras, o no se escriben.
Cuándo empezar
Sí, sin discusión, en la lógica de negocio con dinero de por medio, en cualquier código con reglas que se puedan enumerar, y en todo fallo que ya te haya mordido.
Puede esperar en un prototipo que quizá se tire, o en un script de una vez.
Y una forma pragmática de empezar sin montar nada grande: la próxima vez que arregles un fallo, antes de arreglarlo escribe el código que lo reproduce. Ese es tu primer test, y ya has justificado su existencia.
