Pruebas de regresión visual: Pixel Perfect Forever

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

El problema de la “fuga de CSS”

Eres un desarrollador. Tiene un componente “Botón” utilizado en 50 lugares. Se ve genial. Un día, el equipo de marketing le pide que cambie el margen del pie de página para que el texto de copyright respire. Vas a global.css. Verá una clase genérica .container. Agrega margen inferior: 20px. Presionas el código. Sin saberlo, el “Botón” estaba anidado dentro de un “.contenedor”. Ahora cada botón de la aplicación tiene un margen adicional de 20 píxeles. El diseño del modo “Registrarse” ahora está roto. El botón se presiona fuera de la pantalla. La prueba unitaria pasa: el componente del botón se renderiza sin fallar. El pase de pruebas E2E: Puppeteer podría desplazarse hasta el botón y hacer clic en él mediante programación (a los robots no les importan los cambios de diseño). La experiencia del usuario falló: el usuario cree que su aplicación no funciona. Esto es Regresión visual. Los humanos son notoriamente malos para detectar estos cambios sutiles (“Ceguera al cambio”). Detectar que un tamaño de fuente cambió de 14 px a 13 px en 100 páginas es imposible para un revisor humano. Visual Regression Testing automates this. Implica tomar una captura de pantalla del estado “Aprobado” (Línea base) y compararla píxel por píxel con el estado “Nuevo”. Si incluso el 1% de los píxeles son diferentes, la prueba falla y muestra un “Diff” rojo.

Por qué Maison Code analiza las pruebas visuales

En Maison Code trabajamos con Marcas de lujo. Para un panel SaaS, tal vez sea aceptable un botón desalineado. Para una casa de moda, La estética es funcional. La identidad de marca es el producto. Si el logotipo está desalineado en 2 píxeles o el peso de la fuente no coincide con las pautas de impresión, daña el valor de la marca. Los clientes nos pagan por “Pixel Perfection”. No podemos confiar en el control de calidad manual para detectar “El espacio entre letras tiene un error de 0,1 em”. Implementamos procesos automatizados de regresión visual (usando Percy o Chromatic) para garantizar que ningún “accidente de CSS” llegue a producción. Hacemos que el Sistema de Diseño sea inmutable.

La herramienta: Libro de cuentos + Cromático (o Percy)

Comience con Libro de cuentos. Storybook es un taller para crear componentes de interfaz de usuario de forma aislada. Crea una “Historia” para cada estado de su componente. Botón.historias.tsx:

• Primario (Azul).
• Secundario (Fantasma).
• Destructivo (Rojo).
• Cargando (Spinner).
• Desactivado (Gris).

Chromatic (creado por los mantenedores de Storybook) es el corredor de la nube. Se integra con su CI (GitHub Actions).

1. Construir: CI crea el sitio estático de Storybook.
2. Subir: CI lo sube a Chromatic Cloud.
3. Renderizar: Chromatic activa los navegadores en la nube (Chrome, Firefox, Edge, Safari).
4. Captura: Representa cada historia y toma una captura de pantalla de resolución completa.
5. Comparar: Compara estas capturas de pantalla con la “Línea de base” (la última confirmación en principal).
6. Informe: si los píxeles cambiaron, el estado de compilación es “Pendiente de revisión”.

El flujo de trabajo: revisión de diferencias

El desarrollador abre el panel cromático. Ven “Botón (principal) cambiado”. Alternan la “Vista diferencial” (Diapositiva/Superposición). Ven los píxeles rojos que muestran el cambio. Escenario A (Accidental): “Ups, rompí el acolchado”. -> Acción: Rechazar. Volver al código. Reparar CSS. Escenario B (intencional): “Sí, aumenté intencionalmente el tamaño de fuente”. -> Acción: Aceptar. Esta acción “Aceptar” actualiza la línea base. Las versiones futuras se compararán con esta nueva versión. Esto crea un Pista de auditoría visual. Sabes exactamente cuándo cambió el botón y quién lo aprobó.

Manejo de datos dinámicos (la descamación)

Las pruebas visuales odian los datos dinámicos. Si su componente muestra Date.now(), todas las capturas de pantalla fallarán. Si su componente representa Math.random(), falla. Si carga un avatar de usuario desde randomuser.me, falla. Solución: Datos simulados. Tus historias deben ser Deterministas. Pase accesorios codificados. fecha="2025-01-01T12:00:00Z". Respuestas simuladas de API utilizando Mock Service Worker (MSW) para devolver siempre el mismo JSON. Congelar animaciones. Una captura de pantalla tomada a 0,1 s de una animación gradual será diferente de 0,2 s. Deshabilite las animaciones en el entorno de prueba.

/* vista previa-head.html en el libro de cuentos */
<estilo>
  *, *::antes, *::después {
    animación: ninguna !importante;
    transición: ninguna !importante;
  }
</estilo>

Pruebas entre navegadores

Funciona en tu Mac (Chrome). ¿Funciona en Windows (Edge)? ¿O iPhone (Safari)? Los navegadores representan fuentes y sombras de manera diferente. Las herramientas de regresión visual ejecutan el renderizado en múltiples navegadores reales en la nube. Detectan Errores específicos del navegador. “Falta el degradado en Safari”. “La cuadrícula está rota en Firefox”. Obtienes esta cobertura de forma gratuita sin necesidad de tener un Device Lab.

Pruebas responsivas

No es suficiente realizar la prueba en el escritorio (1920 px). Debes realizar la prueba en tableta (768 px) y móvil (375 px). Tu Grid podría colapsar y convertirse en una pila. Tu menú podría convertirse en una hamburguesa. Cromático le permite especificar ventanas gráficas. ventanas gráficas: [375, 768, 1200]. Se necesitarán 3 capturas de pantalla por componente. Esto triplica tu cobertura. Detectarás al instante los errores de “El botón se superpone al texto en el iPhone SE”.

La visión del escéptico

“Es demasiado caro. Tanto en dinero como en tiempo”. Contrapunto: Dinero: Sí, Chromatic/Percy cuesta dinero (uso de instantáneas). Compare eso con el salario de un ingeniero de control de calidad que hace clic manualmente en 500 pantallas en 3 navegadores. Or the cost of a “Hotfix” when you break the Checkout UI in production. Tiempo: la revisión de instantáneas lleva 1 minuto. “Sí, se ve bien.” Depurar un error de diseño en producción lleva 3 horas. Las pruebas visuales son un gran apalancamiento. Detecta errores que las máquinas (pruebas unitarias) no pueden ver.

Preguntas frecuentes

P: ¿Puedo usar Playwright para esto? R: Sí (esperar(página).toHaveScreenshot()). El dramaturgo es genial. Diferencia: Pruebas visuales de Dramaturgo/Cypress: Ideal para páginas completas (integraciones). “¿La página de inicio se ve bien?” Libro de cuentos/Cromático: Ideal para biblioteca de componentes (átomos). “¿El componente específico ‘Alerta’ se ve bien en las 5 variantes?” Recomendamos ambos. Utilice Chromatic para su sistema de diseño. Utilice Playwright para flujos de usuarios críticos (pagar).

P: ¿Cómo manejo las diferencias de suavizado de 1 px? R: Representar texto es difícil. Las diferencias de GPU provocan cambios de 1 px. Las herramientas tienen configuraciones de “Umbral”. umbral: 0,1. (Se ignoran las diferencias menores al 0,1%). También tienen algoritmos de “detección de suavizado” para ignorar el ruido del suavizado de fuentes.

Conclusión

Las pruebas de regresión visual habilitan “CSS intrépido”. Puede refactorizar toda su arquitectura SASS a Tailwind, y si las capturas de pantalla coinciden al 100%, sabrá con certeza matemática que no rompió nada. Aporta rigor de ingeniería al diseño. Deja de entrecerrar los ojos ante tu pantalla. Deja que el robot lo haga.

13. Manejo de falsos positivos (la regla del 1%)

A veces, los cambios de 1 px son inevitables (actualizaciones del motor de renderizado del navegador). Establecemos un Umbral del 1%. Si la diferencia es <1% del total de píxeles, la prueba pasa automáticamente. Esto filtra el “Ruido” (diferencias de suavizado) pero detecta las “Señales” (botón faltante). También utilizamos regiones de diseño. Le decimos a la herramienta: “Ignora el pie de página (tiene un año de copyright dinámico). Verifica todo lo demás”. Esta “Prueba dirigida” reduce la descamación en un 90%.

14. Por qué Chromatic es mejor que el bricolaje

Intentamos construir esto nosotros mismos con Puppeteer + AWS S3. Fue una pesadilla. Administrar líneas base, paralelizar 500 capturas de pantalla, manejar ramas de git… Cromático resuelve esto. Está construido por los mantenedores de Storybook. Maneja el “Historial de Git” de forma nativa. Sabe que la “Rama de funciones A” debe compararse con la “Rama principal”, no con la “Rama de funciones B”. El costo de €300/mes ahorra €5000/mes en salario de DevOps.

15. Conclusión

El problema con las pruebas visuales es el “ruido”. Si toma una instantánea del contenido dinámico, obtendrá falsos positivos. Implementamos Aislamiento de componentes. Enmascaramos regiones dinámicas con CSS: .dynamic-ad-slot { visibilidad: oculto; }. O nos burlamos de los datos para que sean estáticos. También utilizamos Líneas de base específicas de la sucursal. Al desarrollar una rama de características “feat-new-header”, la comparamos con “main”. Si el encabezado cambia, la prueba falla. Lo marcamos como “Aceptado” en la sucursal. Cuando nos fusionamos con “principal”, esa instantánea aceptada se convierte en la nueva línea de base.

14. El retorno de la inversión de las pruebas visuales

Cuesta € 300 al mes para Chromatic. Esto parece mucho. Compárelo con:

1. Daño a la marca: una marca de lujo con un diseño roto parece un sitio fraudulento.
2. Tiempo de desarrollo: Dedicar 4 horas a arreglar una regresión causada por un cambio global de CSS.
3. Tiempo de control de calidad: pagarle a un humano para que verifique 500 pantallas. El retorno de la inversión suele ser 10 veces mayor. Te permite desplegar los viernes sin miedo.

15. Conclusión

Si está cansado de los ciclos de “arreglé el encabezado pero rompí el pie de página”, Maison Code puede implementar una canalización de pruebas visuales. Configuramos flujos de trabajo Storybook, Chromatic y CI para fijar su diseño en su lugar. Definimos las líneas de base y capacitamos a su equipo sobre cómo revisar las diferencias.

---

Contrate a nuestros arquitectos.