Pruebas de instantáneas HTML

Las pruebas de snapshots registran en la primera ejecución el resultado renderizado de un componente o una página y, en las ejecuciones posteriores, comparan el resultado nuevo con el snapshot guardado. Cualquier cambio en el resultado HTML hace que la prueba falle hasta que el snapshot se actualice de forma intencionada.

El matcher toMatchSnapshot() de Jest serializa un valor (incluido JSX renderizado como HTML) y lo compara con un archivo guardado. npx jest -u actualiza los snapshots cuando se producen cambios intencionados. Las pruebas funcionan como una red de seguridad frente a cambios accidentales en el renderizado.

Storybook Test Runner ejecuta cada story y crea un snapshot de su resultado mediante axe (accesibilidad) y la serialización del DOM. Combinado con Chromatic, añade regresiones visuales: diferencias a nivel de píxel además de diferencias en el DOM.

Percy y Chromatic crean snapshots de las páginas renderizadas como imágenes y muestran las diferencias visuales. Detectan regresiones de CSS que los snapshots del DOM no detectan (un cambio de fuente, un ajuste del margen o una variación de color). Combine snapshots del DOM (económicos y rápidos) con snapshots visuales (costosos y exhaustivos).

Los snapshots que cambian "con demasiada facilidad" se convierten en ruido. Evite crear snapshots de valores inestables (fechas, ids, claves aleatorias). Utilice los property matchers de Jest (expect.any(String)) para los campos que varían legítimamente entre ejecuciones. Mantenga los snapshots pequeños y centrados.

Las diferencias de archivos de snapshots en los pull requests son material de revisión de primera clase. Los revisores comprueban que los cambios del DOM sean intencionados y deseables, y detectan efectos en cascada accidentales derivados de un cambio de CSS "sencillo". Trate las diferencias de snapshots como cualquier otra diferencia.

Hacer snapshots de renderizados enormes de páginas de nivel superior es frágil: cada cambio menor se propaga y genera un diff gigantesco. Haga snapshots a nivel de componente: cada Button, cada Card y cada FormField. Para el renderizado a nivel de página, es preferible usar pruebas de regresión visual.

Elija cómo serializar: HTML completo, DOM simplificado, solo props o árbol de accesibilidad. Cada formato detecta regresiones diferentes. Para componentes de UI, el HTML completo es el más exhaustivo; para lógica basada en props, usar solo props es más económico y rara vez produce falsos positivos.

La causa más común es una refactorización que produce un HTML equivalente, pero con una estructura diferente. Inspeccione el diff: si el cambio es intencionado y positivo, actualice el snapshot. Si es inesperado, corrija el código subyacente. Nunca ejecute jest -u a ciegas sin inspeccionarlo.

Las herramientas de regresión visual renderizan en varios navegadores e informan de las diferencias específicas de cada uno. Utilícelas para detectar CSS que se renderiza de forma diferente en Safari y Chrome, algo habitual en las nuevas funciones de layout durante sus primeras etapas de adopción. Sin snapshots entre navegadores, estas regresiones solo se detectan mediante QA manual.

Las pruebas de snapshot son necesarias, pero no suficientes. Detectan cambios de renderizado no intencionados, pero no errores de lógica (por ejemplo, que al hacer clic en el botón ocurra lo correcto). Combínelas con pruebas unitarias para el comportamiento y pruebas end-to-end para los flujos de usuario; cada capa detecta fallos diferentes.

Las pruebas de snapshot son rápidas: comparan cadenas o archivos. Las pruebas de regresión visual son más lentas (renderizan píxeles, comparan imágenes y, a menudo, usan varios navegadores). Ejecute los snapshots en cada build de CI; ejecute la regresión visual en cada PR, aunque quizá no en cada commit, según el presupuesto de CI.

Las pruebas de snapshot capturan el HTML renderizado en la primera ejecución y señalan cualquier cambio en las ejecuciones posteriores. Utilice Jest toMatchSnapshot para el DOM de los componentes, Storybook Test Runner para las stories y Percy/Chromatic para la regresión visual a nivel de píxel. Haga snapshots a nivel de componente (no de página), excluya los valores inestables y revise cuidadosamente los diffs en los PR. Combínelas con pruebas unitarias y end-to-end para lograr una cobertura completa.