"No regresión" suena a jerga de sala de reuniones, pero es un concepto muy concreto: significa que un cambio nuevo no puede empeorar un comportamiento que ya funcionaba antes de ese cambio. Dicho así parece de sentido común. En la práctica, es la regla que más fácil se rompe cuando se trabaja rápido, porque toda la atención está puesta en lo nuevo y ninguna en lo que ya existía.

Por qué lo nuevo se prueba más que lo viejo

Cuando termino una función nueva, la pruebo con ganas: la toco desde varios ángulos, busco casos raros, la comparo con lo que tenía en mente al diseñarla. Es lógico, es lo que tengo fresco en la cabeza. El problema es que ese cambio nuevo casi nunca vive aislado: comparte código, comparte tablas, comparte pantallas con funciones antiguas que ya daba por buenas.

Sin una regla de no regresión explícita, esas funciones antiguas solo se comprueban si a alguien se le ocurre acordarse de ellas mientras revisa el cambio nuevo. Y la memoria, sobre todo en proyectos que llevan meses, no es un método fiable.

Qué implica en la práctica, no en la teoría

Trabajar con una regla de no regresión implica dos compromisos concretos. El primero: antes de dar por cerrado un cambio, repaso una lista de comportamientos críticos ya existentes y compruebo que siguen igual, no solo que lo nuevo funciona. El segundo: cuando encuentro un fallo, no me limito a corregirlo, sino que dejo una prueba que impida que ese mismo fallo vuelva a pasar desapercibido en el futuro.

Ese segundo punto es el que realmente construye la regla con el tiempo. Cada fallo corregido sin una prueba asociada es una regresión futura esperando a repetirse. Cada fallo corregido con su prueba correspondiente es una regresión que ya no puede volver a pasar en silencio.

Ejemplo práctico

En el desarrollo de la app de mapa de pesca, cambiar cómo se calcula la representación pública de un punto —la zona aproximada que describí en artículos anteriores— es exactamente el tipo de cambio donde una regresión pasaría desapercibida con facilidad. Si al ajustar el radio de esa zona para un caso nuevo, sin darme cuenta, rompo el cálculo para puntos que ya funcionaban bien, el fallo no se ve en la pantalla que estoy probando en ese momento: se ve en una pantalla distinta, con datos distintos, que probablemente no voy a abrir mientras estoy centrado en el caso nuevo.

La regla de no regresión, aplicada aquí, significa tener un conjunto de puntos de ejemplo con su resultado esperado ya conocido, y comprobar que ese resultado no cambia cuando toco el cálculo por otro motivo. Si cambia sin que esa fuera la intención, me detengo antes de continuar.

Cómo decido qué entra en la lista de "no puede romperse"

No todo merece esta protección, porque una lista demasiado larga se vuelve tan pesada de mantener que deja de revisarse de verdad. Prioriza lo que cumple al menos una de estas condiciones: afecta a datos sensibles, afecta a algo que el usuario ve directamente y notaría si cambiara, o ya se ha roto antes sin que nadie lo detectara a tiempo. Esa tercera condición es importante: un fallo que ya ocurrió una vez sin control tiene muchas papeletas de repetirse si no queda protegido explícitamente.

Cómo sostengo esto sin que se convierta en una carga insostenible

Mantener una lista de comportamientos protegidos puede crecer sin control si no se revisa de vez en cuando. Cada cierto tiempo repaso esa lista y me pregunto si cada elemento sigue mereciendo el nivel de atención que tiene: hay comportamientos que dejaron de ser relevantes porque la función que protegían ya no existe en su forma original, y mantenerlos ahí solo añade ruido a la revisión de futuros cambios.

También distingo entre pruebas que deben ejecutarse siempre, en cada cambio, y comprobaciones que reviso manualmente solo cuando el cambio toca directamente esa zona del código. No todo necesita el mismo nivel de automatización constante; forzarlo genera una sensación de seguridad que no siempre corresponde con una inversión de tiempo razonable para un proyecto de este tamaño.

Errores frecuentes al aplicar esta regla

El error más habitual es confundir "tengo pruebas" con "tengo cubierta la no regresión". Se pueden tener muchas pruebas y ninguna de ellas cubrir el comportamiento exacto que después se rompe. El segundo error es tratar la no regresión como una tarea de última hora, justo antes de publicar un cambio, cuando ya hay prisa y poca paciencia para investigar un fallo con calma. Funciona mejor integrada en el propio desarrollo, no como un filtro final.

Conclusión

Al principio, aplicar esta regla se nota casi solo como un coste: más tiempo escribiendo pruebas, más tiempo repasando comportamientos antiguos antes de dar por cerrado un cambio nuevo. La recompensa aparece más adelante, cuando el proyecto ya tiene suficiente historia como para que sea imposible recordar de memoria cada detalle de cómo se comportaba cada parte hace meses. En ese punto, la lista de comprobaciones deja de ser un freno y se convierte en la única forma razonable de seguir avanzando con confianza sobre una base que ya no cabe entera en la cabeza.

Una regla de no regresión no es un documento ni una promesa abstracta, es una lista concreta de comportamientos que se comprueban cada vez que algo cambia cerca de ellos. Cuesta mantenerla, pero cuesta mucho menos que explicar por qué algo que funcionaba la semana pasada ha dejado de hacerlo. Esta disciplina se apoya directamente en documentar bien qué existe y qué no, algo que trato en cómo documento las limitaciones reales de un proyecto.