Qué revisan las pruebas antes de publicar

Antes de que ipe.rest cambie, 137 pruebas pequeñas lo revisan en nuestro propio ordenador. Tardan unos ocho segundos, solo siete de ellas corren también en cada despliegue y hay cosas que ninguna puede ver. Esto es lo que miran.

La entrada de ayer trataba de archivos para máquinas. Esta trata de algo que los lectores nunca ven: las comprobaciones que corren antes de que una página se publique. Las cifras son del 8 de noviembre de 2026, tomadas del repositorio tal como estaba antes de añadir esta entrada: un comando, python3 -m unittest discover tests, 137 pruebas, todas superadas.

Diez archivos, un comando

Las pruebas viven en diez archivos, 1.850 líneas en total. Casi todo el peso recae en el diario: 56 de las 137 tratan de sus páginas. Otras 23 cubren las demás páginas, como acerca de, contacto, privacidad y términos, y 18 cubren la página de inicio. El resto son grupos pequeños: 9 para las notificaciones a buscadores, 8 para los datos estructurados, 7 para el despliegue, 7 para cómo se muestran las horas, 4 para el service worker, 4 para los enlaces y las versiones de los recursos, y 1 para la imagen de vista previa.

Qué detectan

Muchas páginas de aquí se generan a partir de nuestros textos fuente: las entradas del diario, el mapa del sitio, el feed, llms.txt y las tarjetas de la página de inicio. Una prueba falla si algún archivo generado está desactualizado, así que nadie puede editar uno a mano y olvidarse del original.

Otras pruebas vigilan los idiomas. Cada entrada debe tener una versión en cada uno de los doce idiomas, cada página debe enlazar con las demás y consigo misma, y el mapa del sitio debe listar los mismos enlaces que la página. Otras vigilan las reglas que nos hemos puesto: se rechaza una entrada nueva de menos de 300 palabras, una de menos de 400 solo recibe un aviso, se rechaza una entrada con fecha futura y la descripción de una página no puede cortarse con puntos suspensivos.

El service worker, que permite abrir una página sin conexión, tiene un nombre de caché con número de versión. Una prueba comprueba que la versión en los enlaces a recursos de cada página coincide con la que figura en el service worker, de modo que una hoja de estilos modificada no se sirva obsoleta.

Las siete que corren en cada despliegue

Solo un archivo, con 7 de las pruebas, corre en el flujo de despliegue. Comprueba el sitio ya construido, no el repositorio: que estén los archivos que necesita un visitante, que carpetas como scripts y tests no se suban, y que la página 404 esté marcada como noindex y enlace al inicio. Si falla, el despliegue se detiene antes de publicar nada.

Las otras 130 son un hábito, no una barrera. Las ejecutamos antes de confirmar un cambio y nada en el servidor nos obliga a hacerlo.

Lo que no pueden ver

Una prueba superada dice que las páginas concuerdan entre sí, no que sean buenas. Ninguna prueba lee las diez traducciones redactadas por máquina para comprobar su sentido, y por eso esas páginas llevan una nota de traducción por IA. Ninguna prueba de aquí abre un navegador, así que la disposición en una pantalla de móvil estrecha se revisa a ojo. Y no podemos decir si algún rastreador nota el cuidado que ponemos en mantener estos archivos sincronizados.

ipe(); // check the plain things, every time

Casi todo lo que mantiene tranquilo un sitio tranquilo es aburrido: un recuento que coincide, un enlace que resuelve, una versión que avanzó. Preferimos que una máquina lo revise durante ocho segundos a confiar en que lo recordamos.