Pruebas automatizadas: por qué el código no probado es deuda

Casi todos los equipos están de acuerdo, en teoría, en que las pruebas automatizadas son importantes. Y casi todos los equipos, en la práctica, encuentran una excusa para dejarlos de lado. "No tenemos tiempo ahora". "El proyecto es simple." "Probamos manualmente". Son frases que preceden, con impresionante regularidad, el momento en el que todo empieza a romperse.

Las pruebas automatizadas son uno de esos temas en los que la distancia entre el habla y la práctica es enorme. Y esta distancia tiene un costo, que no se paga de una vez, sino en cuotas crecientes a lo largo de la vida útil de un producto.

Este texto trata sobre por qué las pruebas ya no son opcionales y qué cambia realmente cuando un equipo las toma en serio. No es un tutorial. Es un argumento, el argumento de alguien que ha visto, por ambos lados, lo que sucede con y sin pruebas.

¿Qué son realmente las pruebas automatizadas?

Las pruebas automatizadas son programas que verifican automáticamente si su software hace lo que se supone que debe hacer. En lugar de que una persona haga clic y verifique manualmente cada cambio, un conjunto de pruebas realiza esta verificación en segundos, tantas veces como sea necesario.

Pero reducir las pruebas a "verificar que funcionan" es perder el sentido. Las pruebas automatizadas son, ante todo, una red de seguridad. Captan conocimiento sobre cómo debe comportarse el sistema y alertan cuando un cambio rompe ese comportamiento.

Esta red cambia por completo la relación del equipo con el propio código. Sin él, cada cambio es una apuesta. Con ello, cada cambio es una hipótesis verificable.

Por qué esto se volvió no negociable

El software crece y cambia todo el tiempo. Se agregan funciones, se corrigen errores y se reorganiza el código. Cada uno de estos cambios conlleva el riesgo de romper algo que antes funcionaba.

En un sistema pequeño, puedes probar todo a mano. En un sistema real, que crece mes a mes, esto resulta imposible. Nadie puede hacer clic en todos los flujos con cada cambio. El resultado de intentarlo es cansancio, lentitud y bichos que se escapan de todos modos.

Las pruebas automatizadas son la respuesta a este problema de escala. Permiten que el software crezca sin que la verificación se convierta en un cuello de botella humano. Por eso dejaron de ser refinamientos de equipos maduros y se convirtieron en una condición básica para construir algo que perdure.

La tesis: Las pruebas son cuestión de agallas, no de errores

Ésta es mi posición y puede que os sorprenda. El mayor valor de las pruebas automatizadas es no encontrar errores. Es dar coraje para cambiar el código.

Piensa en el equipo sin pruebas. Todo cambio en una parte sensible del sistema va acompañado de miedo. "¿Esto romperá algo más?" Este miedo paraliza. Lleva al equipo a evitar mejoras, a dejar el código incorrecto como está, a no cambiar lo que funciona por puro miedo. El producto se pudre por una cobardía justificada.

Ahora piense en el equipo con buenas pruebas. El mismo cambio va acompañado de confianza. Si algo se rompe, las pruebas te avisan de inmediato. El equipo puede refactorizar, mejorar y evolucionar sin miedo. Esta libertad es el verdadero regalo de las pruebas. No sólo protegen lo que existe, sino que liberan al equipo para construir lo que viene después.

Los tipos de pruebas y cuándo utilizar cada una

No todas las pruebas son iguales y comprender las diferencias evita el desperdicio de esfuerzos.

Las pruebas unitarias verifican fragmentos de código pequeños y aislados. Son rápidos, baratos y deberían ser la base. Detectan errores específicos y brindan retroalimentación casi instantánea.

Las pruebas de integración comprueban si las diferentes partes funcionan bien juntas. Son más lentos, pero detectan los problemas que los unitarios no ven, las fallas que viven en las uniones.

Las pruebas de un extremo a otro simulan el uso en el mundo real, de principio a fin. Son los más lentos y frágiles, pero los más cercanos a la experiencia del usuario. Deben usarse con moderación, en los flujos más críticos.

La sabiduría está en la balanza: muchas pruebas rápidas en la parte inferior, pocas pruebas lentas en la parte superior. Invertir esta proporción es un error clásico que genera suites lentas e inestables que el equipo aprende a ignorar.

Un ejemplo aplicable

Imaginemos un sistema que calcula los beneficios sociales de un programa público. Las reglas son complejas y cambian según la legislación. Un error de cálculo podría significar que un ciudadano reciba una cantidad incorrecta, ya sea más o menos.

Sin pruebas, cada cambio en las reglas es un riesgo enorme. Nadie está seguro de que cambiar una regla no infrinja otra. El equipo es rehén del miedo y los errores acaban llegando al ciudadano.

Con pruebas automatizadas que cubren las reglas de cálculo, cada cambio se compara con docenas de escenarios conocidos en segundos. Si un cambio rompe un caso, el equipo lo sabe antes de publicarlo. La fiabilidad ya no depende de la memoria de nadie y ahora está garantizada por el sistema. En algo que afecta la vida de las personas, esta diferencia no es técnica, es ética.

Las trampas que invalidan el esfuerzo

El primer obstáculo es realizar pruebas por número, no por valor. Los equipos que persiguen un porcentaje de cobertura como objetivo terminan escribiendo pruebas inútiles para inflar la métrica. Una alta cobertura de pruebas erróneas es una seguridad falsa.

La segunda es la suite lenta e inestable. Cuando las pruebas tardan demasiado o fallan aleatoriamente, el equipo pierde la confianza en ellas y comienza a ignorarlas. Una prueba omitida no protege a nadie. El mantenimiento de la suite en sí es un trabajo continuo.

La tercera es tratar las pruebas como una tarea separada, que se realiza más adelante. Las pruebas funcionan mejor cuando son parte del desarrollo, no cuando se convierten en un paso adicional que siempre se deja para el final y nunca sucede.

El código sin prueba es deuda que acumula intereses

Al final, la elección no es entre probar o no probar. Es entre pagar ahora o pagar después, con intereses. El código no probado es una deuda técnica que crece silenciosamente hasta que cobra la factura en el peor momento posible.

Los equipos que invierten en pruebas no son más lentos, son más valientes. Se mueven con la confianza de alguien que tiene una red de seguridad debajo. Y esta confianza, multiplicada por meses y años de desarrollo, es lo que separa los productos que evolucionan de los que se oxidan.

Probar no se trata de desconfiar de su código. Se trata de respetar el futuro de quienes lo mantendrán, incluido usted mismo.

Si su equipo entrega software con miedo de cambiar lo que ya existe, quizás el problema no sea la falta de talento, sino la falta de red. Vale la pena hablar de ello. Tengo otros artículos de blog sobre calidad del software, mejores prácticas e ingeniería que profundizan en cómo generar esa confianza.