Por qué las pruebas de regresión son críticas hoy

Qué son realmente las pruebas de regresión

Una prueba de regresión vuelve a verificar un comportamiento que ya funcionaba, después de un cambio. Es lo contrario de probar una función nueva: nadie pidió que el checkout cambiara, así que si se comporta distinto tras la entrega de hoy, esa diferencia es el hallazgo.

Tampoco es lo mismo que una reprueba. Reprobar confirma que un error concreto está corregido. La prueba de regresión hace la pregunta más amplia que plantea esa corrección: ¿qué más tocó ese cambio? Una corrección de una línea en una regla de envío puede mover un total, una edición de plantilla puede eliminar un campo del formulario y subir una dependencia puede cambiar cómo se interpreta una fecha.

El disparador es cualquier cambio, no solo tu código: la actualización de un plugin o de un paquete, un cambio de configuración o de entorno, un cambio de CDN o de DNS, un script de terceros que se actualiza solo, contenido editado en un gestor. Cada uno puede alterar un comportamiento que nunca tocaste, y por eso las pruebas de regresión son un hábito continuo y no un acto del día de la entrega.

Por qué importan más ahora

La IA generativa cambió la economía de escribir código. Una función que llevaba un día lleva una hora; una refactorización para la que nadie tenía tiempo ocurre por capricho. Lo que no cambió es la necesidad de que el resultado sea correcto, y el modo de fallo de un asistente de IA no se parece al de una persona. No duda, no se detiene, no deja un TODO. Produce algo plausible, completo y fluido, sea correcto o no.

Esto se ve en hechos concretos. Los modelos inventan cosas que no existen: un estudio sobre alucinaciones de paquetes encontró que en torno a uno de cada cinco paquetes recomendados por modelos generadores de código no era real, lo que es a la vez un fallo y un riesgo de cadena de suministro, porque un atacante puede registrar ese nombre inventado. Además reescriben más de lo pedido: el análisis de GitClear sobre cientos de millones de líneas modificadas describe un aumento de la duplicación y una caída de la refactorización, la firma de código que se añade en lugar de reorganizarse.

Lo peligroso es la brecha de percepción. En un ensayo aleatorizado de METR, desarrolladores de código abierto con experiencia trabajando en sus propios repositorios fueron medibles más lentos con asistencia de IA, mientras creían haber sido bastante más rápidos. Sentirse rápido es exactamente cuando se salta la verificación, y la investigación DORA de Google ha relacionado la mayor adopción de IA con una menor estabilidad de las entregas. Velocidad sin red de seguridad es como una regresión silenciosa llega a los clientes.

Hay un efecto de segundo orden: cada vez más código de tu repositorio no lo escribió nadie del equipo desde cero, y se revisa en diferencias más grandes de las que alguien lee con atención. La memoria institucional —«cuidado, esa función sostiene medio sistema»— se diluye. Las pruebas de regresión automáticas son lo que sustituye a esa memoria.

Los tipos de pruebas de regresión

Las pruebas de regresión no son una única técnica. Los tipos clásicos describen cuánto vuelves a ejecutar: la regresión unitaria repite solo las pruebas alrededor de la unidad modificada, de forma aislada. La regresión parcial (selectiva) repite la unidad cambiada más lo que depende de ella, elegido por análisis de impacto; es el valor por defecto habitual, porque es lo bastante rápido para cada commit. La regresión completa lo repite todo y se reserva para un cambio grande o arriesgado: una actualización de framework, una migración de plataforma o una rama de larga vida que por fin se integra. La reprueba total es la versión por fuerza bruta: ejecutar toda la batería, haya cambios o no, normalmente en una programación y no por commit.

Otros dos describen qué clase de cambio estás protegiendo: la regresión correctiva repite las pruebas existentes sin tocarlas, porque cambió el código pero no la especificación. La regresión progresiva actualiza primero las pruebas, porque la propia especificación se movió: se espera un comportamiento nuevo y lo que se busca es confirmar que nada fuera de ese comportamiento se movió con él.

Después están las capas, que importan más que las etiquetas. La regresión funcional y de extremo a extremo recorre recorridos reales de usuario —añadir al carrito, finalizar la compra, pagar, recibir la confirmación— y es la única capa que demuestra que el negocio sigue funcionando. La regresión de API y de contrato fija la forma de una respuesta, de modo que un campo que cambia de tipo en silencio se detecta antes de que rompa a quienes lo consumen. La regresión visual compara los píxeles renderizados con una línea base aprobada y detecta lo que una aserción sobre el DOM nunca verá: un diseño que se desmonta, una tipografía que falla, una imagen que desaparece. La deriva de estructura trabaja una capa más abajo, sobre el DOM, y detecta lo que los píxeles no ven, como un script de seguimiento o un campo de formulario que desapareció sin cambiar la imagen. La regresión de rendimiento compara tiempos con una línea base, porque una página que sigue funcionando pero ahora tarda cuatro segundos es una regresión real. La regresión de datos y esquema vuelve a comprobar migraciones e informes con entradas conocidas. La regresión de accesibilidad y de SEO detecta lo que es invisible para ti: una etiqueta perdida, una regla noindex que se fue en producción con una configuración de pruebas.

Dónde se detiene tu batería de pruebas

Todos los tipos anteriores prueban el código que controlas, en el momento en que lo cambias. Tu sitio en producción se compone de mucho más: actualizaciones automáticas de plugins y paquetes, la actualización de un tema, una pasarela de pago que cambia su incrustación, un script de terceros que se actualiza de madrugada, una regla de CDN, una subida de versión de PHP o de Node por parte del alojamiento, contenido editado con prisa.

Nada de eso toca tu repositorio, así que nada de eso ejecuta tus pruebas, y todo ello ha roto sitios en producción. El fallo más común que vemos no es un mal despliegue: es un plugin de WordPress o de WooCommerce que se actualiza solo a las tres de la mañana y cambia el checkout, en un sitio cuyo código no cambió esa semana. Una tubería de CI en verde no dice nada de ninguno de estos casos.

Ese es el hueco que llenan las comprobaciones continuas en producción: la misma disciplina de pruebas de regresión, apuntada al sitio que está en marcha en vez de a la compilación. La línea base es lo que tu sitio hacía ayer; el hallazgo es lo que cambió hoy, lo cambiara quien lo cambiara, incluidas las personas y los robots que nunca abrieron tu repositorio.

Qué vigilar de forma continua, por orden

Empieza por el camino del dinero. Una comprobación de extremo a extremo del recorrido que paga las facturas —añadir al carrito, finalizar la compra, pedido realizado, correo de confirmación recibido— vale más que cien pruebas unitarias, porque es el fallo que cuesta dinero por hora. Relvato lo ejecuta como un recorrido de supervisión del checkout contra la tienda real, de forma programada y tras cada actualización.

Después, las dos capas de representación, que detectan mitades distintas de un despliegue roto: regresión visual para el aspecto de la página y deriva de estructura para cómo está construida. Añade Core Web Vitals para tratar una regresión de velocidad como lo que es, y un análisis de exposición para que una clave o una copia de seguridad que aparezca en una compilación se descubra el mismo día, y no por otra persona.

El principio de orden es simple: protege primero lo que se rompe más ruidosamente y luego amplía. Un conjunto pequeño de comprobaciones que realmente se ejecutan vale más que una batería exhaustiva que nadie mantiene, y a diferencia de una batería de pruebas, las comprobaciones en producción conservan su valor aunque el cambio venga de fuera de tu repositorio.

Si no tienes ninguna batería de pruebas

Muchos sitios que ganan dinero de verdad no tienen pruebas automáticas, y el consejo de «escribe primero una batería de pruebas» es justo lo que hace que siga siendo así un año más. Hay un atajo: empieza por fuera. Un puñado de recorridos en producción puede estar funcionando hoy mismo sin tocar tu código, y te dirán a los pocos minutos de un mal cambio que algo de lo que depende un cliente ha dejado de funcionar.

A partir de ahí, empuja hacia dentro. Cuando una comprobación en producción detecte una regresión, ese es el comportamiento que merece fijarse con una prueba unitaria o de integración, escrita con el fallo delante. Tu batería crece entonces a partir de incidentes reales y no de conjeturas sobre lo que podría romperse, que además es la forma más barata de construirla.

La verdad incómoda de la era de la IA es que generar código ya no es el cuello de botella; saber si funciona, sí. Las pruebas de regresión son la manera de averiguarlo a propósito, en vez de enterarte por un cliente.