Las pruebas visuales de un design system consisten en verificar automáticamente la apariencia de cada componente UI — botones, formularios, cards, modales — tanto de forma aislada (en Storybook o equivalente) como en su contexto real (dentro de las páginas de la aplicación), para detectar regresiones visuales en cada cambio.
Los design systems se han convertido en el estándar para los equipos de front-end. Para una introducción al tema, consulta nuestra guía de pruebas de regresión visual y nuestra guía de pruebas visuales para principiantes. Un conjunto de componentes reutilizables, documentados, versionados. Limpio. Mantenible. Y aun así, los bugs visuales se cuelan. Aquí está el porqué.
La trampa del componente perfecto en aislamiento
Tienes un componente "Card" en tu design system. Lo pruebas en Storybook. Es perfecto: los márgenes son correctos, los colores respetan la marca, la tipografía es conforme. Todo está en verde.
Lo integras en una página con una grid de 3 columnas, una sidebar y un header. Y ahí, la Card desborda su columna. El texto se solapa con el componente vecino. El botón de acción queda parcialmente oculto por el footer.
El componente es perfecto. La página está rota. La prueba en aislamiento no podía detectarlo.
Esta es la trampa fundamental: un componente nunca existe solo. Interactúa con sus vecinos, con el layout padre, con el contenido real. Probar en aislamiento es probar en un vacío que no existe en producción.
Por qué ambos niveles son necesarios
Las pruebas de componentes aislados responden a una pregunta: "¿se muestra correctamente el componente en sí en todos sus estados?". Botón activo, inactivo, hover, focus. Card con título corto, título largo, sin imagen. Modal abierta, cerrada. Estas pruebas protegen el design system como librería.
Las pruebas de páginas completas responden a una pregunta diferente: "¿funcionan los componentes juntos en el contexto real de la aplicación?". ¿El layout aguanta? ¿Los componentes evitan superponerse? ¿El responsive funciona cuando 5 componentes comparten el mismo espacio?
Ambas preguntas son legítimas. Y ninguna cubre el espectro completo por sí sola.
Las herramientas para cada nivel
Para los componentes aislados, Chromatic (integrado a Storybook) es la referencia. Cada story se convierte automáticamente en una prueba visual. Es eficaz para proteger la librería de componentes.
Para las páginas completas, hace falta una herramienta que pruebe páginas reales con recorridos de usuario reales. Es el dominio de Delta-QA (sin código), Playwright (con código) o Percy (SaaS). Para un tutorial de Playwright, consulta nuestra guía completa.
El problema con el que se encuentran muchos equipos: invierten masivamente en pruebas de componentes vía Chromatic y descuidan las pruebas de páginas completas. Resultado: la librería está protegida, pero la aplicación no. Para una comparativa de las principales herramientas, consulta nuestro ranking 2026.
Las regresiones que solo las páginas completas detectan
Conflictos de layout entre componentes vecinos. Dos componentes que funcionan perfectamente en aislamiento pero se solapan cuando comparten un grid CSS.
Efectos de cascada CSS. Un cambio de estilo en un componente padre que impacta el render de todos sus hijos. En aislamiento, el componente hijo no tiene padre — el bug es invisible.
Problemas de responsive en contexto real. Un componente que es responsive en aislamiento (se adapta al ancho de su contenedor) pero que se rompe cuando su contenedor cambia de tamaño en función del viewport.
Contenido real vs contenido de demo. Las stories de Storybook usan datos de demostración limpios y calibrados. En producción, los usuarios meten títulos de 200 caracteres, imágenes en retrato en vez de paisaje, texto en árabe que invierte la dirección. Este último caso es particularmente complicado en cross-browser: consulta nuestra guía de pruebas visuales cross-browser para los detalles.
Consistencia entre páginas. Tu botón "Comprar ahora" puede verse perfecto en una página y ligeramente diferente en otra debido a padding heredado, ancho de contenedor u overrides de tema. Solo las pruebas a nivel página detectan esta deriva.
La estrategia recomendada
Usa Chromatic (o equivalente) para proteger tu librería de componentes. Cada componente, cada estado, cada variación. Es la primera red de seguridad.
Usa una herramienta de pruebas de páginas completas para proteger la aplicación en sí. Páginas críticas, recorridos de usuario principales, layouts complejos. Es la segunda red.
Ninguna basta por sí sola. Juntas, cubren el espectro completo.
Cómo priorizar qué probar
No puedes probarlo todo. Decide en función del impacto y la frecuencia de cambio.
A nivel componente, céntrate en:
- Componentes usados en más de 5 páginas (Button, Input, Card, Modal, Table)
- Componentes con muchos estados (campos de formulario, toggles, dropdowns)
- Componentes que cambian con frecuencia (cada release introduce nuevas variaciones)
A nivel página, céntrate en:
- Páginas de conversión (checkout, registro, pricing)
- Páginas de mucho tráfico (homepage, dashboard, resultados de búsqueda)
- Páginas con layouts complejos donde varios componentes del design system interactúan
- Páginas donde una regresión sería costosa comercial u operativamente
Un componente usado una sola vez en una página de admin interna no necesita el mismo escrutinio que un Button usado en todas partes.
Storybook + una herramienta a nivel página: la combinación ganadora
Las configuraciones de QA de design system más eficaces que hemos visto combinan ambas capas explícitamente:
- Storybook con Chromatic se ejecuta en cada PR que toca
packages/design-system/*. Las regresiones a nivel componente bloquean la PR antes de que llegue a main. - Una herramienta de pruebas a nivel página se ejecuta en cada PR que toca código de aplicación. Las regresiones de página bloquean la PR antes de que se despliegue.
Los dos sistemas comparten la misma filosofía de comparación (estructural o perceptual, según la herramienta) pero operan en niveles de abstracción diferentes. Un bug que escapa a la capa de componente se atrapa en la capa de página. Un bug invisible en aislamiento se manifiesta cuando importa: en contexto.
¿Y la mantenibilidad de las pruebas?
Es la objeción más habitual: "Dos capas significan el doble de mantenimiento".
En la práctica, no. Cada capa atrapa bugs distintos. Si solo tuvieras la capa de componente, compensarías con QA manual a nivel página — más lento y menos fiable. Si solo tuvieras la capa de página, cada variación de componente requeriría su propia prueba de página — explosivo en cuenta.
Dos capas, bien configuradas, generan menos falsos positivos y necesitan menos mantenimiento que una sola capa intentando hacer ambas cosas.
FAQ
¿Basta Chromatic si usamos Storybook?
Para proteger la librería de componentes, sí. Para proteger la aplicación completa, no. Los bugs de layout, los problemas de cascada CSS y los problemas de contenido real solo son visibles a nivel página.
¿Hay que probar todos los componentes visualmente?
Céntrate en los componentes compartidos (Button, Input, Card, Modal, Table) y en aquellos con muchos estados. Los componentes simples y poco modificados pueden excluirse. Prueba donde el impacto y la frecuencia de cambio son más altos.
¿Cómo probar páginas completas sin código?
Con una herramienta como Delta-QA. Navegas a la página, la herramienta captura el estado, y compara automáticamente en ejecuciones siguientes. No hace falta Storybook ni código.
¿Las pruebas de componente detectan los problemas de tema?
Sí, si tienes stories para cada tema (claro/oscuro). Pero no detectan problemas de tema en contexto — por ejemplo, un componente que cambia mal de tema cuando está anidado en otro.
¿Las pruebas de componente deberían bloquear despliegues?
Para componentes compartidos usados en todo el design system: sí. Una regresión en Button impacta cada página. Para componentes únicos usados en una sola feature: caso por caso. Bloquea lo que sería costoso de revertir en producción.
¿Cómo introducir este enfoque de dos capas en un equipo nuevo?
Empieza por la capa de página. Atrapa las regresiones de mayor impacto inmediatamente y demuestra valor. Añade la capa de componente cuando Storybook esté establecido y los contribuidores se sientan cómodos creando stories. El orden inverso rara vez funciona — los equipos que adoptan las pruebas de componente primero suelen saltarse la capa de página porque se sienten "cubiertos".
Un design system protege la consistencia. Las pruebas visuales protegen la realidad. Probar tus componentes en aislamiento es verificar que los ladrillos son buenos. Probar tus páginas completas es verificar que la casa se mantiene en pie.
Para profundizar
- Delta-QA vs Chromatic: ¿Componentes Aislados o Páginas Completas?
- Delta-QA vs Chromatic: ¿Páginas completas o componentes aislados?
- Test Visual: Componentes Aislados vs Páginas Ensambladas — ¿Qué Nivel Importa Realmente?