Por qué mis tests pasaban mientras mi blog estaba roto en producción

¿Alguna vez revisaste algo con cuidado, viste todas las señales en verde, y el resultado terminó estando roto de todas formas? A mí me pasó con mi propio sitio web. Escribí el código, corrí cada prueba automática que tengo configurada, y todas pasaron. El problema es que ninguna de esas pruebas estaba mirando lo mismo que iba a ver un visitante real.

Este sitio es mi portafolio, y lo construyo dirigiendo IA contra un proceso con reglas escritas y controles automáticos antes de dar algo por terminado. Uno de esos controles revisa que cada página se vea bien, otro que sea accesible, otro que el código compile sin errores. La sección del blog pasó todos, uno por uno.

Y aun así, cada post que publiqué se rompía por completo apenas alguien real lo abría. La página mostraba un mensaje de error genérico. Ni una palabra del artículo se veía.

Lo que me llevé

• Un chequeo automático solo prueba lo que de verdad ejecuta. Si corre en un entorno más permisivo que el real, puede decir que todo está bien cuando en producción no lo está.
• El arreglo más fácil no siempre es el correcto, sobre todo cuando debilita algo importante como la seguridad.
• Arreglar un bug visible a veces destapa uno invisible que vivía justo al lado, en silencio.

Cómo mi blog terminó mostrando un error genérico

El contenido del blog está escrito en un formato que mezcla texto normal con pedacitos de código: se llama MDX. Antes de que puedas leerlo, algo tiene que convertir ese formato en algo que el navegador entienda.

Mi sitio tiene una política de seguridad que bloquea una técnica específica para generar código sobre la marcha dentro del navegador. Los navegadores la llaman eval, y es una puerta de entrada común para ataques, así que la bloqueo a propósito. Resulta que la pieza que convertía el formato del blog en texto legible usaba justo esa técnica, adentro del navegador de cada visitante.

Por qué mis pruebas nunca lo notaron

Todas mis pruebas corrían contra una versión de desarrollo del sitio, y esa versión sí permite la técnica bloqueada, porque la necesita para otra cosa: actualizar la página mientras programo, sin recargarla entera. Nadie decidió eso a propósito para el blog. Fue una suposición vieja que nunca se revisó: que solo esa otra cosa necesitaba el permiso.

Entonces mis pruebas de accesibilidad pasaban. Las de diseño visual pasaban. El chequeo de que la página carga sin errores pasaba. Todas corrían contra la versión que sí tiene el permiso, nunca contra la versión real que ve un visitante.

¿Por qué no simplemente permitir esa técnica en producción?

Porque esa política de seguridad existe para bloquear ataques reales, y esa técnica específica es una de las puertas más comunes que usan. Quitarle esa restricción a todo el sitio, para arreglar un solo problema del blog, hubiera dejado la puerta abierta en cualquier otra parte donde alguien pudiera inyectar algo. El arreglo tenía que evitar la técnica, no permitirla.

Un arreglo que debilita la seguridad de todo el sitio para resolver un problema de una sola sección no es un arreglo. Es una deuda que vas a pagar en otro lado.

Arreglar esto destapó un segundo bug escondido

La solución real fue mover esa conversión al servidor, donde esa técnica sí está permitida porque nunca corre en el navegador de nadie. El texto del blog llega al visitante ya convertido, listo para leer.

Ese cambio arregló el problema principal, pero destapó uno segundo. Uno de los bloques de código del blog tenía un botón para copiarlo con un clic. Ese botón vivía en la parte del sitio que corre en el navegador. Al mover la conversión al servidor, esa pieza dejó de conectarse bien, y el botón desapareció sin ningún error, en silencio.

Lo encontré comparando la versión nueva con la versión de antes, línea por línea, no porque algo me avisara. Ahora tengo 2 pruebas dedicadas justo a esto: una que revisa que ninguna parte del código que corre en el navegador intente hacer esta conversión, y otra que abre un post de verdad y confirma que el botón de copiar sigue ahí.

Si alguna vez viste todo en verde y aun así algo se rompió en producción, ya conoces esa sensación. Lo bueno es que cada control que falló en silencio, arreglado de verdad, se vuelve un control que la próxima vez sí te avisa. Gracias por leer hasta acá. 🙂