Las pruebas visuales con Chromatic te permiten detectar cambios de UI en tus componentes de Storybook y validarlos en equipo antes de mergear. Si trabajas en un design system, esta herramienta agiliza el QA visual y conecta a desarrollo con diseño en un mismo flujo de feedback.

¿Qué son las pruebas visuales y por qué importan en un design system?

Una prueba visual compara cómo se veía tu componente antes y después de un cambio en el código. En lugar de revisar manualmente cada background, color o medida, Chromatic captura snapshots de cada historia de Storybook y resalta las diferencias.

Esto importa porque un design system vive del trabajo colaborativo. Tus compañeros de desarrollo pueden aprobar el cambio, y el equipo de diseño puede validar que el resultado respeta los lineamientos. Sin esa capa de revisión, cualquier ajuste de color o espaciado puede romper la consistencia que tanto cuesta construir.

¿Qué hace Chromatic exactamente? Captura imágenes de tus componentes de Storybook en cada publicación y te muestra qué cambió a nivel de UI, para que el equipo apruebe o rechace antes de hacer merge.

¿Cómo instalar Chromatic en tu proyecto de Storybook?

La instalación es directa y se conecta con tu repositorio de GitHub para mantener el historial de cambios visuales [00:53].

• Ejecuta npm install chromatic en la raíz de tu proyecto.
• Crea una cuenta en Chromatic y conéctala con GitHub.
• Selecciona el repositorio del proyecto que quieres versionar visualmente.
• Copia el comando con el token único que te genera Chromatic.
• Corre ese comando en la terminal para publicar tu Storybook por primera vez [02:30].

Al finalizar la primera publicación, Chromatic detecta automáticamente cuántos componentes e historias tienes. En el ejemplo del transcript, identificó dos componentes con dos historias y los dejó listos para futuras comparaciones.

¿Qué pasa si tu repositorio no aparece en Chromatic?

Solo aparecen los repositorios donde tienes permisos. Si trabajas sobre un fork o un repo de la organización al que no estás vinculado, créate un proyecto alternativo en tu cuenta personal y trabaja desde ahí. Esa fue la salida que se aplicó con un repo llamado Storybook Base para poder seguir el flujo.

¿Cómo detecta Chromatic un cambio visual en tu UI?

Una vez publicado el Storybook por primera vez, cualquier modificación posterior se compara contra ese baseline. Si cambias un color, un background o cualquier propiedad visible, Chromatic lo señala.

El flujo práctico se ve así: modificas una story, por ejemplo cambiando un token de color de primary50 a primary, guardas, y vuelves a correr el comando de publicación con tu token. Chromatic procesa los snapshots y, si hay diferencias, te muestra una pantalla con el componente afectado y la propiedad exacta que cambió, en este caso el background [05:40].

¿Qué es un baseline en pruebas visuales? Es la versión aprobada de tus componentes que Chromatic guarda como referencia. Cada nueva publicación se compara contra ese baseline para detectar diferencias.

Desde esa pantalla puedes aceptar el cambio si es intencional, o rechazarlo si fue un error. Lo interesante es que la decisión no es solo tuya: el equipo recibe la notificación y puede dar su aprobación, simulando un flujo real de revisión entre desarrollo y diseño.

¿Cómo aprobar cambios y mergear con feedback del equipo?

Cuando aceptas un cambio visual en Chromatic, la plataforma marca esa versión como aprobada y habilita el siguiente paso: el pull request. Es decir, el cambio queda validado visualmente antes de integrarse al código principal.

• Aceptas el cambio en la interfaz de Chromatic.
• El equipo recibe la simulación del cambio y lo aprueba.
• Chromatic te indica que ya puedes hacer el merge en GitHub.
• En tu panel de componentes queda registrado quién aprobó qué.

Esta trazabilidad es clave en un design system porque cada decisión visual queda documentada. No es solo "cambié un color", es "cambié este color, lo aprobaron estas personas, en esta fecha, sobre este componente".

¿Por qué Chromatic encaja en el flujo de un design system?

Un design system exige documentación, reuniones y acuerdos constantes entre equipos. Herramientas como Chromatic reducen la fricción porque convierten esas conversaciones en aprobaciones rastreables sobre componentes reales, no sobre capturas sueltas en un chat.

El resultado es un proceso de QA visual que respeta los flujos del equipo y deja evidencia de cada iteración. Cuéntame en los comentarios qué cambio visual probaste primero en tu Storybook con Chromatic y cómo reaccionó tu equipo al feedback.