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 con 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. No se veía ni una palabra del post.

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 ejecutar texto como código dentro del navegador, una técnica que usa eval. Bloquearla limita lo que podría hacer un script inyectado. 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 permitirla habría debilitado una protección de todo el sitio para resolver un problema del blog. Quería mantener esa restricción y cambiar cómo se compilaba el contenido, para que el navegador no necesitara ejecutar código a partir de texto.

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 la compilación ya no depende de los permisos del navegador del visitante. El texto del blog llega al visitante ya convertido, listo para leer.

Ese cambio arregló el problema principal, pero destapó otro. 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. Para mí, la lección fue probar el entorno que de verdad usan los visitantes y revisar qué más pudo cambiar con el arreglo. Gracias por leer hasta acá. 🙂