Hay cambios de código que se pueden probar tocando la app un par de minutos y viendo si "se ve bien". Y hay otros que no se pueden probar así, porque el fallo no se nota en pantalla: se nota en un dato que ha salido a donde no debía salir. Cualquier cosa que toque coordenadas privadas, cuentas de usuario o permisos entra en la segunda categoría, y para esa categoría tengo una rutina de pruebas que no me salto aunque el cambio parezca pequeño.

Por qué un cambio "pequeño" puede ser el más peligroso

La intuición dice que un cambio grande necesita más pruebas que uno pequeño. Con datos sensibles esa intuición falla. Un cambio de una línea en un endpoint —por ejemplo, añadir un campo a una respuesta JSON para "facilitar" algo en el cliente— puede filtrar una coordenada base sin que ninguna prueba visual lo detecte, porque la pantalla sigue mostrando exactamente lo mismo que antes.

Por eso, antes de cualquier cambio que toque una tabla o un endpoint relacionado con datos sensibles, me obligo a hacer una pausa y aplicar la misma lista, sin importar el tamaño del cambio.

La lista que reviso antes de tocar el código

Primero, identifico qué campos son sensibles en ese contexto concreto: no es lo mismo la coordenada base de un punto de pesca que su representación pública, ni es lo mismo un correo de contacto que un nombre de usuario visible. Escribo esa lista antes de escribir una sola línea de código nuevo.

Segundo, reviso cada respuesta de API que pueda verse afectada por el cambio y me pregunto quién puede recibir esa respuesta: ¿solo el propietario autenticado? ¿cualquier usuario autenticado? ¿cualquiera, sin sesión? Si el cambio mueve un dato sensible a una respuesta con una audiencia más amplia que antes, se detiene ahí.

Tercero, compruebo los casos límite de permisos: usuario sin sesión, usuario autenticado pero no propietario, usuario propietario, y —cuando aplica— administrador. Cada uno de esos cuatro casos tiene que dar un resultado explícito, no un resultado "por omisión" que nadie decidió a propósito.

Ejemplo práctico

Imaginemos que quiero añadir una función para que un usuario pueda ver "puntos cercanos" a su posición actual. La tentación rápida es reutilizar la consulta que ya devuelve puntos con su coordenada base, filtrando por distancia, y simplemente no mostrar ese campo en el cliente. Esa aproximación falla la prueba de la respuesta de API: aunque el cliente no pinte la coordenada base, si la respuesta la incluye, cualquier inspección del tráfico de red la expone igual.

La versión que sí pasa la prueba construye la consulta de cercanía en el servidor usando la coordenada base internamente, pero devuelve en la respuesta solo la coordenada de presentación de cada punto cercano. El filtrado de distancia usa el dato preciso; la respuesta expone solo el dato aproximado. Ese matiz —calcular con un dato y exponer otro— es exactamente lo que reviso en cada endpoint nuevo.

Pruebas automatizadas frente a revisión manual

Las pruebas manuales son necesarias, pero no bastan para este tipo de cambios, porque dependen de que alguien recuerde probar el caso correcto. Por eso las reglas más importantes —"la coordenada base nunca aparece en una respuesta pública", "un usuario no propietario nunca recibe el campo X"— las convierto en pruebas automatizadas que se ejecutan siempre, no solo cuando me acuerdo.

No hace falta una batería enorme. Con un puñado de pruebas que cubran los casos de permisos descritos arriba, cualquier cambio futuro que rompa esa garantía falla de forma visible antes de llegar a producción, en lugar de fallar en silencio delante de un usuario real.

Por qué añado una segunda mirada antes de fusionar el cambio

Las pruebas automatizadas comprueban lo que alguien pensó comprobar en el momento de escribirlas, y ese "alguien" suele ser yo mismo, con mis propios puntos ciegos. Por eso, cuando el cambio afecta a datos sensibles, no me conformo con que las pruebas pasen: reviso el propio código del cambio como si lo hubiera escrito otra persona, buscando específicamente respuestas de API nuevas o modificadas, condiciones de permisos y cualquier campo que se añada a un modelo de datos existente.

Esa revisión suele tardar poco, pero cambia el tipo de error que se detecta. Las pruebas automatizadas atrapan bien las regresiones sobre comportamiento ya conocido; la revisión de código atrapa mejor los casos nuevos que nadie había pensado todavía en forma de prueba, precisamente porque nadie sabía que había que comprobarlos hasta que se mira el cambio completo con calma.

Límites de este enfoque

Ninguna lista de pruebas elimina el riesgo por completo. Las pruebas automatizadas cubren lo que se les pide que cubran; si aparece una nueva vía de acceso a un dato sensible que nadie previó al escribir la prueba, esa vía queda sin cubrir hasta que se detecta y se añade. Por eso esta rutina se complementa, no sustituye, con una revisión de código específica cuando el cambio afecta a datos sensibles: una segunda mirada humana antes de fusionar el cambio.

Tampoco resuelve los problemas que vienen de fuera del propio sistema, como metadatos incrustados en archivos subidos por el usuario. Esa es una capa distinta de revisión, con sus propias comprobaciones.

Conclusión

Cuando el dato en juego es sensible, la pregunta que me hago no es "¿funciona?" sino "¿a quién le llega y con qué precisión?". Esa pregunta cambia el tipo de pruebas que hay que escribir y obliga a mirar las respuestas de API con más cuidado que la pantalla. Es la misma lógica que aplico al separar la coordenada exacta de la que se muestra, como explico en cómo separar una coordenada privada de su representación pública.