¿Qué es el testing de regresión visual? Capturas de pantalla como aserciones

El testing de regresión visual toma una captura de pantalla de tu interfaz, la compara con una aprobada de antes y falla cuando han cambiado píxeles que nadie acordó cambiar. Es el único tipo de prueba que detecta que un cambio de hoja de estilos ha movido un botón cuatro píxeles a la izquierda, porque eso no es un comportamiento que ninguna aserción fuera a describir jamás.

Todo lo demás se deduce de un hecho incómodo: una captura de pantalla no es determinista, y una prueba que no es determinista acaba siendo ignorada.

Qué produce una ejecución

Tres imágenes por comprobación, y la tercera es la única que alguien mira.

• La baseline - la captura aprobada, versionada junto al código.
• La candidata - lo que la interfaz renderiza ahora.
• El diff - las dos superpuestas, con los píxeles cambiados marcados.

Una comprobación pasa cuando la candidata coincide con la baseline, y falla en caso contrario. Fallar no es lo mismo que estar mal: un rediseño deliberado hace fallar todas las comprobaciones que toca, y el arreglo es aprobar las nuevas capturas como baselines. Ese paso de aprobación es donde está el trabajo de verdad.

Los fallos que no son fallos

Casi todo lo difícil de esto son falsos positivos, y salen de una lista corta de las mismas causas de siempre.

• El antialiasing y el renderizado de fuentes. El mismo texto en dos máquinas, o con dos controladores gráficos, no son los mismos píxeles.
• Cualquier cosa que muestre la hora actual. Una marca de tiempo, un “hace 3 días”, un año en el copyright.
• Los datos dinámicos. Una lista ordenada por novedad, un nombre sacado al azar de una fixture, un número que crece.
• Las animaciones y las transiciones. Una captura tomada a mitad de una transición es cara o cruz.
• Las fuentes que llegan tarde. La captura se toma antes de que cargue la webfont, así que la baseline tiene una tipografía y la candidata otra.
• Las barras de desplazamiento. Distintas según el sistema operativo, y a menudo dentro del área capturada.

Cada una tiene un arreglo aburrido: congelar el reloj, sustituir los datos por otros fijos, desactivar la animación, esperar a que las fuentes se asienten y hacer cada captura en un único entorno controlado en lugar de en la máquina que esté libre. Docker es la respuesta habitual a lo último, y es la mayor fuente de ruido si te lo saltas.

Es decir que una suite visual es un problema de tests flaky con otro sombrero. Se aplica la misma regla: una comprobación que falla por motivos ajenos al código deja de leerse, y una suite que nadie lee es peor que no tener suite, porque sigue costando tiempo.

Los umbrales son el primer instinto equivocado

La respuesta obvia al ruido es permitir que difiera un porcentaje de píxeles. Funciona, y también es la forma en que se cuela un defecto real.

Débil

Fallar si difiere más del 0,5 % de los píxeles - que es margen de sobra para que un botón se mueva, un precio cambie o una etiqueta de formulario desaparezca en una página grande

Mejor

Tolerancia cero, con regiones excluidas por su nombre: el reloj de la cabecera, el avatar, el gráfico que se redibuja. Cada exclusión es una decisión que alguien escribió

Un umbral global es una declaración de que una fracción desconocida de tu interfaz puede cambiar sin avisarte. Una región ignorada es una declaración sobre un elemento concreto, revisable en un pull request, y no crece en silencio a medida que la página se hace más grande.

Lo que no te puede decir

No te puede decir que un cambio esté mal. Te dice que ha habido un cambio, y una persona decide cuál de las dos cosas es.

Parece una distinción menor hasta que cuentas las revisiones. Cada cambio visual deliberado produce una cola de diffs que alguien tiene que mirar y aprobar, y si esa persona no tiene nombre, la cola se convierte en un sello de goma en un mes. Momento en el cual la suite se ejecuta, está verde y no vale nada.

Además solo comprueba aquello a lo que la apuntaste, en los navegadores y tamaños de ventana que le indicaste. Esta es la brecha que merece nombrarse, porque es donde viven los errores interesantes. Un diseño que se rompe solo en Safari, o solo a 320 píxeles de ancho, o solo cuando el navegador no puede decodificar el vídeo que estás sirviendo, es invisible para una suite que captura Chrome a un único tamaño.

Cuándo se gana el sueldo

El patrón es la repetición. El testing visual sale a cuenta donde los mismos componentes se renderizan muchas veces de formas que una persona no puede volver a revisar en la práctica.

Un sistema de diseño o una biblioteca de componentes es el caso más claro: un cambio de padding lo toca todo, y la suite te dice exactamente qué tocó. Las páginas de marketing son el segundo, porque son sobre todo maquetación y una rota cuesta dinero directamente. Cualquier cosa renderizada en varios idiomas o temas es el tercero - la misma página en siete idiomas son siete oportunidades para que una traducción sea más larga que su contenedor, y nadie abre las siete a mano en cada release.

Se gana mucho menos en una interfaz que se rediseña cada semana, donde cada ejecución es un muro de aprobaciones, y en pantallas internas donde un defecto cosmético le cuesta a alguien un encogimiento de hombros.

Dónde encaja junto a todo lo demás

El testing de regresión visual son pruebas de regresión con una captura de pantalla como aserción, así que la misma lógica decide qué entra en ellas: cosas que funcionaban y tienen que seguir funcionando. Tu plan de pruebas debería decir qué páginas están cubiertas y, más útil todavía, cuáles no.

Tampoco es lo mismo que el reporte visual de errores, pese a la palabra compartida, y los dos responden preguntas opuestas. Una suite visual encuentra cambios no intencionados antes de que nadie los vea, en los entornos que elegiste. Un informe de error te dice qué salió mal para una persona real, en el navegador que tiene de verdad, en la página que estaba usando de verdad. Ninguno sustituye al otro: el primero es una red, el segundo es lo que haces con el pez que se coló.

No vendemos una herramienta de testing visual, y este es el límite honesto de lo que podemos contarte sobre usar una. Lo que nosotros vemos es el otro extremo - el informe que llega porque algo se renderizó mal para alguien, en un navegador o un tamaño de pantalla que nadie capturó.

Un punto de partida que sobrevive al contacto

Cinco páginas, un navegador, un tamaño de ventana, ejecutándose en CI en cada pull request, en un contenedor para que los píxeles sean estables. Una persona con nombre aprueba los diffs. Regiones excluidas en lugar de un porcentaje.

Añade navegadores y tamaños cuando las cinco páginas lleven un mes en verde y con confianza. La mayoría de las suites que se abandonan eran demasiado amplias el primer día, y las que sobreviven empezaron más pequeñas de lo que parecía serio.