Pruebas en microfrontends: una estrategia práctica

Cada equipo puede probar bien su remoto y el producto igual puede romperse donde las piezas se juntan. Una estrategia de pruebas para microfrontends pone la mayor parte del esfuerzo adicional en esas uniones.

Qué cambia frente a una sola app

En una aplicación única, una ejecución de pruebas revisa un build. En una plataforma de microfrontends, lo que ve el usuario se arma en el navegador con partes que se compilaron y publicaron en momentos distintos. Ningún pipeline produce la aplicación completa. La combinación que corre hoy en producción puede no haber existido nunca en un ambiente de pruebas.

Por eso la estrategia tiene dos objetivos. Cada remoto debe poder probarse solo y rápido. Y los contratos entre el host y los remotos deben verificarse sin obligar a todos a publicar juntos.

Las capas

Pruebas unitarias y de componentes por remoto

Un remoto es una aplicación normal. Sus pruebas unitarias y de componentes corren en su propio pipeline, con el runner que prefiera el equipo, y no necesitan nada de otros equipos. La mayor parte del volumen de pruebas debe vivir en este nivel.

Hay una regla que importa: el remoto también debe correr de forma independiente, con un mock pequeño de lo que entrega el host (usuario, permisos, navegación, tema). Ese mock hace que las pruebas de integración del remoto sean rápidas y estables. Es la misma pieza que se usa para el desarrollo local.

Pruebas de contrato entre host y remotos

El contrato es todo lo que cada lado asume sobre el otro:

• Los nombres de los módulos expuestos y lo que exportan.
• Las rutas que le pertenecen a cada remoto.
• La API que el host entrega a los remotos: sesión, usuario, permisos, navegación.
• Los eventos que se intercambian entre áreas y sus payloads.

Pon el contrato en un paquete de tipos pequeño y versionado. Después verifícalo en ambos lados:

1. Lado del remoto. Una prueba carga el remoto compilado y revisa que cada módulo expuesto exista y exporte lo que dice el contrato.
2. Lado del host. Una prueba monta un remoto falso mínimo que cumple el contrato y revisa que el host lo cargue, navegue hacia él y le pase la sesión.
3. Eventos. Cada evento publicado tiene un esquema. El productor prueba que emite payloads válidos. El consumidor prueba que maneja los ejemplos del esquema.

Pact encaja bien para las APIs HTTP que consume cada remoto, y su soporte de mensajes puede cubrir los payloads de eventos. Para el contrato entre host y remoto, un paquete de tipos y las pruebas anteriores suelen ser suficientes. La parte de eventos se describe en comunicación entre microfrontends.

Pruebas end-to-end de los recorridos críticos

Las pruebas end-to-end contra el producto compuesto son lentas y caras de mantener estables, así que conviene tener pocas. Elige los recorridos donde una falla cuesta dinero o confianza: el inicio de sesión, el flujo principal de transacción, todo lo que cruce dos o más áreas.

• Usa una sola herramienta para toda la plataforma. Playwright es una opción común.
• Asigna un dueño a cada recorrido. Una prueba que falla y no tiene dueño termina desactivada.
• Deja el comportamiento detallado de cada pantalla a las pruebas del propio remoto.

Probar con distintas versiones de remotos

La pregunta clave antes de publicar es: ¿mi versión nueva funciona con lo que está en producción en este momento?

Una forma práctica de responderla:

1. Compila la versión nueva del remoto y publícala en una URL de vista previa.
2. Corre las pruebas de humo contra el host de producción y las versiones de producción de los demás remotos, reemplazando solo tu remoto.
3. Haz el reemplazo sobrescribiendo el manifiesto. Playwright puede interceptar la petición del manifiesto con page.route y devolver una copia modificada.

El host hace lo mismo al revés: su versión nueva se prueba contra las versiones de producción de todos los remotos.

Así se revisa la combinación real que va a existir después del despliegue. Un ambiente compartido de staging, donde cada equipo despliega trabajo sin publicar, no puede darte esa respuesta.

Después del despliegue

Como el ensamblaje final ocurre en el navegador, la última prueba corre en producción. Después de cada publicación, corre las pruebas de humo contra el sitio real, con cuentas y datos reservados para ese fin, y vigila la tasa de errores del remoto que cambió. Si alguno de los dos falla, revierte desde el manifiesto. Más en aislamiento de errores y resiliencia y CI/CD para microfrontends.

Más en esta sección

• Monorepo vs polirepo para microfrontends
• De monolito frontend a microfrontends, paso a paso
• Una app AngularJS legacy dentro de un host de microfrontends
• Equipos, límites de propiedad y ley de Conway