Test Visual y Docker: Sin Entorno Reproducible, tus Screenshots No Valen Nada
Entorno reproducible: configuración software idéntica en cada ejecución — mismo sistema operativo, mismas bibliotecas, mismas fuentes, mismo motor de renderizado — garantizando que los resultados de un test no varíen según la máquina donde se ejecuta. — Principio fundamental de la ingeniería de test automatizado.
Has implementado test visual. Comparas screenshots. Tus tests pasan en local. Y cuando se ejecutan en la CI, obtienes 47 diferencias señaladas — ninguna corresponde a un bug real.
Este escenario lo ha vivido la gran mayoría de equipos que hacen test visual. Y la mayoría saca la conclusión equivocada: «El test visual genera demasiado ruido, no funciona.»
El test visual funciona perfectamente. Lo que no funciona es tu entorno.
Un screenshot tomado en macOS con fuentes Apple nunca será idéntico al píxel a un screenshot tomado en Ubuntu con fuentes FreeType. Un navegador a 1920x1080 con escalado 100% no produce el mismo renderizado que uno a 1920x1080 con escalado 125%. El antialiasing, el hinting de fuentes, el suavizado subpíxel — todo difiere.
Docker resuelve este problema. Y si haces test visual sin Docker, estás perdiendo el tiempo.
Por qué los screenshots difieren de una máquina a otra
Renderizado de fuentes: el culpable número uno
Cada SO usa su propio motor de renderizado tipográfico. macOS usa Core Text, Windows usa DirectWrite, Linux usa FreeType. El mismo texto, misma fuente, mismo tamaño — no produce los mismos píxeles según el SO.
Además, las fuentes disponibles varían entre sistemas. Si tu CSS especifica una fuente no instalada en la máquina de CI, el navegador usa una fuente de respaldo que puede cambiar todo el layout.
El motor de renderizado del navegador
Chrome 120 no produce exactamente el mismo renderizado que Chrome 122 para ciertas propiedades CSS.
La resolución y el escalado
El DPI de tu pantalla influye en el renderizado. Los servidores de CI usan framebuffers virtuales cuya configuración puede diferir de tu máquina de desarrollo.
Docker: el entorno idéntico, cada vez
Docker encapsula el entorno completo de test en un contenedor. Mismo SO, mismas fuentes, mismo navegador, misma versión — ya sea en tu puesto macOS, un runner GitHub Actions o una instancia EC2.
Lo que debe contener el contenedor
Fuentes (instaladas localmente), navegador en versión fija, configuración de renderizado explícita (fontconfig, DPI del framebuffer virtual, antialiasing), y dependencias del sistema para el navegador headless.
La imagen base: no reinventes la rueda
Las imágenes oficiales de Playwright son un excelente punto de partida. Parte de una imagen que funciona, añade tus fuentes y configuración específica.
Dockerizar tu setup: pasos clave
- Fijar las versiones — nada de "latest", nada de ranges semánticos
- Construir la imagen — capas estables arriba, código que cambia abajo
- Validar la reproducibilidad — construir dos veces, los resultados deben ser idénticos
- Integrar en CI/CD — push al registro, referenciar el tag exacto
- Gestionar actualizaciones — ritmo mensual, regenerar baselines
Beneficios más allá de la reproducibilidad
Paralelización
Lanza 10, 20, 50 contenedores en paralelo. Tests de 30 minutos en secuencial pasan a 3 minutos en paralelo.
Aislamiento de tests
Cada contenedor parte de un estado limpio. Sin caché ni cookies residuales.
Dónde se ubica Delta-QA
El análisis estructural de Delta-QA es inherentemente menos sensible a variaciones de renderizado. Donde una comparación píxel a píxel señala cada diferencia de subpíxel, Delta-QA analiza propiedades CSS calculadas — márgenes, paddings, dimensiones, posicionamiento — que son iguales independientemente del entorno.
Esto no significa que Docker sea inútil con Delta-QA. Pero la tolerancia a variaciones es incomparablemente mayor. Para equipos que no pueden invertir en una imagen Docker dedicada, es una ventaja decisiva.
Errores frecuentes a evitar
- Usar "latest" como tag — primera causa de tests inestables
- Olvidar las fuentes — instálalas localmente en el contenedor
- Ignorar el tamaño del viewport — configúralo explícitamente en la herramienta
- No versionar la imagen — push al registro con tag exacto
FAQ
¿Docker es obligatorio para test visual?
No, pero sin Docker pasarás tiempo considerable gestionando falsos positivos.
¿Qué imagen base recomiendan?
Las imágenes oficiales de Playwright (mcr.microsoft.com/playwright).
¿Docker ralentiza los tests?
El arranque añade segundos, pero la paralelización compensa con creces.
¿Cómo gestionar Google Fonts en Docker?
Descarga los archivos e instálalos localmente en el contenedor.
¿Delta-QA necesita Docker?
No. Funciona sin Docker gracias a su análisis estructural. Docker sigue siendo buena práctica pero no es prerequisito.
Un screenshot que cambia de una máquina a otra no es un test. Es ruido. Docker transforma tus capturas en pruebas fiables y reproducibles.