¿Para qué escribimos tests? (El CTO que no entendía nada)

Muchas veces debatimos sobre arquitecturas, sobre patrones de diseño, sobre creación de sistemas... Y son temas súper importantes, pero no son la parte importante del software.

Porque, ¿para qué creamos software en primer lugar? ¿Para qué nos pagan?

Pues la respuesta es sencilla: para resolver problemas. Con software creamos valor resolviendo diferentes problemas dentro de un negocio. Puede que hagamos ganar más dinero, puede que reduzcamos el coste de hacer las cosas... Pero al fin y al cabo creamos software para tener un impacto.

Y tener esto presente es lo más importante. El software que no resuelve el problema para el que fue creado no vale nada, por muy elegante que sea su arquitectura.

El CTO que no entendía los tests

Y precisamente por eso me sorprende tanto cuando me encuentro con equipos que ignoran esto completamente.

En mi carrera he conocido muchos tipos de desarrolladores y muchos tipos de empresa. He conocido grandes tinkerers y grandes profesionales. Y en ese ecosistema tan variado he encontrado más ocasiones de las que quisiera a esos extraños seres que no hacen tests.

Un compañero me comentaba que un día su anterior CTO se acercó a él y le puso cara pensativa: "¿Tests? ¿Para qué, no?". Mi compañero no duró mucho después en esa empresa.

Ya no entramos ni siquiera en la discusión de los defectos (o bugs), si tenemos más o menos casos esquina que pueden darnos problemas. Simplemente el hecho de validar que nuestro software en efecto funciona como esperamos que funcione y aporte el valor que ha de aportar ya es una de las cosas más importantes en esto de crear software.

Sin tests no puedes afirmar con certeza que tu código hace lo que debería hacer. Punto.

Los tests manuales: caros y poco fiables

Ahondando un poco más en el caso de mi compañero conseguí sonsacarle que sí que hacían tests. Pero eran tests de esos que decimos que son caros. Básicamente tenían a varias personas probando manualmente la aplicación para ver que todo fuera correctamente. O sea tests, pero los más caros posibles.

Ahí la discusión ya migra a gestión de costes. Si una persona manualmente tiene que probar cada versión de nuestro software que desplegamos al mundo, esas pruebas serán muy caras. Y si son tan caras se acabarán haciendo poco y mal.

Por esos motivos hemos de valorar tanto los tests automáticos. Esos que escribes una vez y que de forma gratuita van a validar que el software que has creado en efecto hace lo que tiene que hacer.

La inversión que siempre vale la pena

Piénsalo así: cada test automático que escribes es como contratar a un robot que va a trabajar para ti gratis durante toda la vida del proyecto. Cada vez que hagas un cambio, cada vez que despliegues, ese ejército de robots silenciosos verificará que no has roto nada.

¿Inviertes tiempo al principio? Sí. ¿Vale la pena? Absolutamente.

"Pero es que no tengo tiempo para escribir tests"

Esa frase la he escuchado exactamente 47 veces en mi carrera. ¿Sabes cuántas veces esos mismos equipos tenían tiempo para arreglar bugs en producción a las 2 AM? Las 47.

La realidad es que no tienes tiempo para NO escribir tests. Cada minuto que inviertes en tests automáticos te ahorra horas de debugging, reuniones de crisis y parches de emergencia.

La conclusión es simple

El software crea valor, resuelve problemas. Y poder garantizar con certeza que lo hace de verdad es una de las cosas más (si no la más) importante de nuestro oficio. Testea, y que no sea a mano.

Porque tu código sin tests es como un piloto volando sin instrumentos. Quizás llegues a destino... o quizás no. ¿De verdad quieres jugártela?

El Siguiente Paso: La GUÍA TÁCTICA de Testing

Vale, este post se centra en el "por qué". Por qué los tests no son negociables para garantizar que nuestro software aporta valor.

Pero una vez que estamos convencidos de por qué (y de que hacerlo a mano es una mala idea), la siguiente pregunta lógica es... ¿cómo?

¿Son todos los tests iguales? ¿Cuesta lo mismo hacer un test que prueba un login completo que uno que prueba una simple función de cálculo?

Para responder a esto, he grabado mi último vídeo. Es la guía táctica que necesitas para entender las diferencias de coste y beneficio entre los distintos tipos de tests.

En este vídeo nos vamos al código y analizamos los tres niveles principales de la pirámide de testing, viendo sus pros y sus contras:

1. Tests Unitarios: Los más rápidos y "baratos" de crear y ejecutar. Son perfectos para testear la lógica de negocio "pura" (como una función que calcula un precio) sin dependencias externas.
2. Tests de Integración: Un escalón por encima en coste. Los usamos cuando necesitamos verificar cómo interactúan varios componentes entre sí, o con una dependencia externa como una base de datos.
3. Tests End-to-End (E2E): Los "caros pero caros". Simulan un flujo de usuario completo en la aplicación real (como usar Playwright para probar un login). Son difíciles de mantener, pero vitales para los flujos más críticos de tu negocio.

El objetivo es que, como desarrolladores, podamos tomar decisiones informadas sobre qué tipo de test usar en cada momento, equilibrando siempre el coste de crearlo con el valor que nos aporta.