Proceso de pruebas visuales con Cypress

Pruebas visuales con Cypress sin capturas inestables

Respuesta breve

Cypress puede capturar la página, pero no compara imágenes por sí solo. Un proceso visual añade un complemento o servicio de comparación, fija el estado del navegador y la aplicación, guarda una referencia aprobada y conserva la imagen actual y el diff como evidencia de CI. Una diferencia pide revisión, no demuestra automáticamente un fallo del producto.

Revisado por Equipo de producto de RenderLogActualizado
Comparación de una captura de Cypress con una referencia aprobada y cambios de interfaz destacados

Cypress es eficaz para crear el estado que debe representar una captura. Puede abrir una ruta, interceptar una respuesta inestable, fijar el viewport y comprobar una señal visible de que la interfaz está lista. El comando de captura registra ese estado. La comparación, el almacenamiento de referencias y la aprobación dependen de un complemento, un servicio alojado o un proceso separado.

Esta guía sigue una comprobación de la página de precios desde el desarrollo local hasta CI. Se centra en las decisiones que evitan falsos errores: qué datos fijar, cuándo está lista la página, dónde guardar la referencia y quién aprueba un cambio. También explica cuándo RenderLog complementa mejor a Cypress para páginas públicas revisadas por producto, marketing, operaciones o clientes.

Define qué debe controlar Cypress antes de elegir la comparación

Mantén el proceso en Cypress cuando la prueba deba iniciar sesión, crear registros, interceptar una API o recorrer una interacción antes de capturar. Esa cercanía al código aporta valor: el fallo puede bloquear una integración y el desarrollador puede reproducir el mismo estado localmente. Describe primero la ruta, el viewport, el usuario, el idioma, el tema, los datos de prueba y el elemento que confirma que la interfaz terminó de renderizar.

Instalar un complemento de capturas no crea un proceso de revisión. Decide si las referencias vivirán en Git, en un almacén de artefactos o en un panel alojado. Define quién aprueba una imagen nueva y cómo queda registrada la decisión. Sin una responsabilidad clara, el equipo acabará aceptando actualizaciones sin criterio o ignorando fallos aunque la comparación de píxeles funcione de forma técnicamente correcta.

  • Usa Cypress para estados que requieren fixtures, intercepciones o flujos de usuario.
  • Nombra el viewport, idioma, tema y estado de cuenta en cada comprobación.
  • Elige el almacenamiento y el responsable antes de crear la primera referencia.
  • Separa la vigilancia programada de páginas públicas cuando tenga otro responsable.

Haz reproducible el estado antes de tomar la captura

Una página de precios puede incluir fecha actual, moneda regional, planes remotos, fuentes web, chat y testimonios rotatorios. Fija solo las variables ajenas a la afirmación. Intercepta la respuesta de precios si pruebas el diseño, configura zona horaria e idioma y desactiva animaciones mediante una opción prevista por el producto. Conserva los datos reales cuando su cambio sea precisamente el riesgo que quieres revisar.

Espera una condición visible en vez de una pausa fija. Comprueba que aparezcan el título y las tarjetas esperadas y espera una señal conocida de la aplicación. Cypress reintenta muchos comandos, lo que resulta más fiable que dormir una duración estimada. Si falta una tarjeta, la prueba debe informarlo como causa funcional antes de convertirlo en una diferencia visual grande y ambigua.

  • Intercepta datos inestables solo cuando sus valores no formen parte de la prueba.
  • Fija viewport, zona horaria, idioma y esquema de color.
  • Utiliza aserciones reintentables como señales de disponibilidad.
  • Oculta únicamente la región dinámica irrelevante más pequeña posible.

Aprueba una referencia revisada, no la primera imagen correcta

Ejecuta la prueba y examina la imagen completa antes de convertirla en referencia. Confirma que cargaron las fuentes, que el aviso de consentimiento tiene el estado previsto, que hay datos y que ningún widget tapa una llamada a la acción. La primera captura satisfactoria solo es candidata. Se vuelve útil cuando una persona confirma que representa el estado que el producto debe conservar.

Cuando llega un cambio de diseño intencionado, actualiza solo las imágenes afectadas a partir de resultados revisados. Mantén visibles la versión anterior y la nueva en la solicitud de cambios o el sistema de revisión. Un comando global de actualización es rápido, pero puede aprobar una sección ausente junto con el color esperado. Las aprobaciones pequeñas conservan el vínculo con una decisión real del producto.

  • Revisa cada primera candidata a referencia a tamaño completo.
  • Actualiza solo las imágenes afectadas por el cambio intencionado.
  • Conserva referencia, captura actual y diff en cada fallo de CI.
  • Registra a la persona o solicitud que aprobó el nuevo estado.

Ajusta las reglas de comparación con evidencias

Empieza con la comparación práctica más estricta en un navegador y runner fijados. Si los bordes de las letras cambian entre local y CI, iguala primero fuentes, versión del navegador e imagen del sistema. Si una miniatura de vídeo cambia siempre, sustitúyela o excluye solo esa región. Un umbral global alto puede ocultar un botón desplazado en otra parte de la página.

Examina el diff junto con las dos imágenes que lo originaron. Un porcentaje no explica si los píxeles son suavizado inocuo o un control de compra ausente. Prefiere capturas de componentes cuando una región pequeña necesite otra regla y capturas completas cuando importe la composición. Documenta cada tolerancia junto a la prueba para que otro responsable entienda qué variación pretende absorber.

  • Fija el entorno antes de medir la variación normal.
  • Investiga dónde aparecen los cambios antes de aumentar la tolerancia.
  • Captura un componente por separado si necesita su propia regla.
  • Trata el porcentaje como ayuda de revisión, no como veredicto del producto.

Haz que un fallo de CI se entienda sin repetir el trabajo

Sube la referencia, la captura actual, el diff y los registros de Cypress para cada fallo. Los nombres deben indicar especificación, navegador y viewport. Una persona debe poder distinguir una modificación del producto de una página que nunca cargó sin volver a ejecutar el trabajo. Si la biblioteca produce un informe HTML, consérvalo durante al menos el ciclo habitual de revisión del equipo.

Clasifica antes de actualizar. Un timeout de disponibilidad es un fallo de prueba o entorno. Una página estable sin una tarjeta de precio es una diferencia del producto. Un rediseño revisado es un cambio esperado y puede generar otra referencia. El ruido repetido alrededor de fuentes señala deriva del entorno. Esta separación evita aceptar imágenes solo para recuperar una compilación verde.

  • Guarda referencia, resultado, diff, registros e informe de la prueba.
  • Incluye navegador y viewport en nombres o metadatos.
  • Separa los fallos de ejecución de las comparaciones completadas.
  • Exige revisión antes de promover un cambio esperado.

Usa RenderLog para revisiones compartidas o programadas

Las comprobaciones del repositorio encajan con aserciones que deben bloquear código. Una página pública de precios, un sitio de cliente o una campaña pueden tener otra frecuencia y otro responsable. RenderLog guarda esa página como comprobación, la ejecuta por calendario o API y mantiene referencia aprobada, resultado, diff e historial en una interfaz que no requiere acceso al CI de Cypress.

No dupliques todas las pruebas. Elige páginas donde el bloqueo de una versión y la vigilancia continua sean tareas distintas. Cypress puede cubrir un checkout preparado antes de integrar código, mientras RenderLog revisa cada mañana la página de precios en producción. Asocia cada proceso con una acción: ingeniería corrige el estado del repositorio y producto u operaciones revisan la página pública.

  • Mantén en Cypress los estados que deben bloquear una integración.
  • Lleva la revisión programada de páginas públicas a una superficie compartida.
  • No dupliques un estado sin otro responsable y otra acción.
  • Usa la API de RenderLog cuando otro sistema deba iniciar el proceso.

¿Complemento de Cypress, API de capturas o RenderLog?

Los tres enfoques trabajan con capturas, pero resuelven responsabilidades distintas. Elige según la acción posterior a una diferencia, no solo por la forma de obtener la imagen.

DecisiónComparación en CypressAPI de capturasRenderLog
Mejor encajeEstado ligado al código y control de integraciónUna aplicación solo necesita la imagenRevisión repetida con responsabilidad compartida
Control del estadoFixtures, intercepciones, comandos y asercionesOpciones de petición y lógica del clienteComprobaciones, escenarios, calendarios y API
Revisión de referenciaGit, artefactos de CI o servicio del complementoDebe construirla el clienteReferencia, resultado, diff e historial juntos
Responsable habitualIngeniería y revisión de códigoEquipo de la aplicación clienteIngeniería, producto, operaciones, agencia o cliente

Proceso mínimo de comparación visual con Cypress

Los ejemplos muestran control de estado, comparación y evidencias de CI como pasos distintos. Adapta los comandos al complemento elegido, porque Cypress captura imágenes pero no las compara por sí solo.

cypress.config.ts

import { defineConfig } from "cypress";

export default defineConfig({
  viewportWidth: 1366,
  viewportHeight: 768,
  video: false,
  e2e: {
    baseUrl: "http://127.0.0.1:3000"
  }
});

cypress/e2e/pricing.cy.ts

describe("pricing page", () => {
  it("matches the approved desktop state", () => {
    cy.intercept("GET", "/api/prices", { fixture: "prices.json" }).as("prices");
    cy.visit("/pricing");
    cy.wait("@prices");
    cy.contains("h1", "Pricing").should("be.visible");
    cy.get("[data-testid=plan-grid]").compareSnapshot("pricing-desktop");
  });
});

CI artifact handoff

npx cypress run --browser chrome
# Upload cypress/screenshots/ and the visual plugin's diff output on failure.
# Keep scheduled public-page review in RenderLog when it has a non-code owner.

Fuentes primarias de esta guía

Los comandos y la configuración de Cypress cambian. Consulta la documentación oficial para los detalles actuales y utiliza esta guía para las decisiones de proceso, responsabilidad y aprobación.

Continúa con la capa adecuada de pruebas visuales

Vigila una página de producción fuera de la suite

Deja que Cypress controle los estados ligados al código y guarda una página pública de precios, registro o campaña en RenderLog cuando otras personas necesiten evidencias programadas y un historial claro.

Crear un espacio de RenderLog