Si tu equipo hace apps en Flutter y ya tiene tests unitarios y de widget, llega el momento de automatizar los flujos completos: abrir la app, iniciar sesión, pagar, cerrar. Ahí aparecen dos nombres: Patrol y Maestro. No hacen lo mismo y la elección no es de gusto. Patrol vive dentro de tu app y habla Dart; Maestro la prueba desde fuera y se escribe en YAML. Esa diferencia decide casi todo lo demás.
La respuesta corta: elige Patrol si tu equipo es de desarrolladores Flutter y necesitas llegar al estado interno de la app y a los diálogos nativos del sistema. Elige Maestro si quieres flujos de humo rápidos, que los escriba también QA sin tocar Dart, o pruebas que crucen varios frameworks. Abajo está el porqué, con el coste de cada decisión.
Qué es cada uno
Patrol es un framework open source de LeanCode construido encima de integration_test, el paquete de pruebas de integración del propio Flutter. Mantiene tus tests en Dart y añade lo que a integration_test le falta: control del sistema operativo. Puede aceptar un permiso, abrir el panel de notificaciones, interactuar con un diálogo nativo de permisos o con el selector de archivos. Lo hace con puentes a la instrumentación de cada plataforma: UIAutomator en Android y XCUITest en iOS. La versión actual pide Dart 3.12 o superior, y las últimas releases incluyen skills para agentes de IA como Claude, un detalle que importa si ya automatizas parte de tu desarrollo con agentes.
Un apunte para no perder una tarde: el paquete oficial es patrol. Existe un fork llamado patrol_plus que mantiene un tercero, no LeanCode. Si abres una incidencia, mira primero cuál tienes instalado.
Maestro es un framework open source de mobile.dev que prueba la app desde fuera, como caja negra. Los tests se escriben en YAML, en flujos legibles que describen pasos: lanza la app, pulsa este botón, escribe esto, comprueba que aparece aquello. No le importa en qué está hecha la app: funciona con Flutter, React Native, nativo, híbrido. Trae tolerancia a la asincronía incorporada, con esperas y reintentos, que es donde más sufren las suites de E2E. El runner local es gratis; la nube de dispositivos (Maestro Cloud) se paga.
La diferencia de fondo: dentro o fuera de la app
Patrol es caja blanca. El test corre dentro del proceso de tu app, así que alcanza el árbol de widgets por Key, puede leer y tocar estado de Dart, y combinar esa precisión con la automatización nativa del sistema. Un mismo test pulsa un botón de tu UI, concede el permiso de cámara en el diálogo del sistema y vuelve a tu pantalla sin cambiar de herramienta.
patrolTest('login con permiso de notificaciones', ($) async {
await $.pumpWidgetAndSettle(const MiApp());
await $(#email).enterText('demo@dribba.com');
await $(#password).enterText('••••••••');
await $(#login).tap();
await $.native.grantPermissionWhenInUse(); // diálogo nativo del SO
await $(#inbox).waitUntilVisible();
});
Maestro es caja negra. No entra en tu app: la mira desde fuera, identifica elementos por texto o por identificadores de accesibilidad y actúa sobre ellos. El mismo login se ve así:
appId: com.dribba.miapp
---
- launchApp
- tapOn: "Correo"
- inputText: "demo@dribba.com"
- tapOn: "Entrar"
- assertVisible: "Bandeja de entrada"
De esa diferencia salen todas las ventajas y todos los límites de cada herramienta.
Cuándo elegir Patrol
Patrol encaja cuando el equipo que escribe los tests es el mismo que escribe la app y quiere un único lenguaje de las pruebas unitarias a las E2E. Si tu suite ya está en Dart, Patrol no te obliga a cambiar de mundo.
Es la opción cuando el test necesita tocar el interior: comprobar un estado concreto, inyectar un mock de una dependencia, o afirmar sobre algo que no se ve en pantalla pero tiene que ser cierto. Y es la opción cuando el flujo cruza la frontera de la app hacia el sistema: permisos, biométrica, deep links, notificaciones push, el selector nativo de ficheros. Esos pasos son justo los que integration_test a secas no cubre y los que más fallan en manos de otras herramientas.
El coste: mantienes código de test en Dart, con sus Key y sus finders, y eso se mantiene como cualquier código. Si tu equipo de QA no es fluido en Dart, Patrol les deja fuera. Y es Flutter y poco más: para web, Playwright sigue siendo mejor opción.
Cuándo elegir Maestro
Maestro gana cuando quieres cobertura rápida de los flujos críticos sin montar una infraestructura de test en código. Un flujo de humo que verifique "la app arranca, el login funciona, el carrito suma" se escribe en Maestro en diez minutos y lo entiende quien lea el YAML.
Es la opción cuando quien escribe los tests no es del equipo de desarrollo. Una persona de QA sin Dart puede mantener la suite. Y es la opción cuando pruebas varias apps hechas con stacks distintos, o incluso una app de la que no tienes el código fuente: al ser caja negra, a Maestro le da igual. La tolerancia a la asincronía que trae de serie reduce esos fallos intermitentes que erosionan la confianza en una suite de E2E.
El coste: al no entrar en la app, no puedes afirmar sobre el estado interno ni mockear nada a nivel de Dart. Para interacciones finas con widgets complejos de Flutter, te quedas corto frente a una herramienta nativa. El runner local es gratis, pero la nube de dispositivos se paga por dispositivo y mes, y con paralelismo la factura sube rápido. Y hay curva: el YAML es sencillo, pero cuando un flujo pide lógica de verdad (condicionales, bucles, datos dinámicos) el DSL se queda justo.
Tabla de decisión
| Criterio | Patrol | Maestro |
|---|---|---|
| Enfoque | Caja blanca, dentro de la app | Caja negra, desde fuera |
| Lenguaje | Dart | YAML |
| Quién lo escribe | Desarrolladores Flutter | Desarrollo o QA, sin Dart |
| Estado interno / mocks | Sí | No |
| Flujos nativos del SO (permisos, notificaciones) | Sí, de serie | Limitado |
| Multiframework / app sin fuentes | No, solo Flutter | Sí |
| Tolerancia a flakiness | La gestionas tú | Incorporada |
| Coste | Open source; pagas tu infra de dispositivos | Runner local gratis; nube de pago |
El error que vemos antes de elegir herramienta
La pregunta "¿Patrol o Maestro?" llega a menudo demasiado pronto. El E2E es la punta de la pirámide de tests: el nivel más lento, más caro de mantener y más frágil. Antes de automatizar veinte recorridos completos, conviene tener bien cubiertos los tests unitarios y de widget, que corren en milisegundos y atrapan la mayoría de los fallos. Si vuelcas en E2E lo que debería estar en una capa inferior, acabas con una suite lenta en la que el equipo deja de confiar, y da igual qué framework la ejecute. Lo tratamos a fondo en nuestra guía de testing en Flutter.
Un segundo matiz: las dos herramientas dependen de selectores, Key en Patrol, texto o identificadores de accesibilidad en Maestro. Ninguna elimina el mantenimiento de esos selectores cuando la UI cambia. Hay una nueva hornada de herramientas que prometen resolverlo con IA; es una decisión aparte, y hoy no es la que tienes delante.
Nuestra recomendación
Para un equipo Flutter que controla su código y quiere una sola suite coherente, nosotros empezamos por Patrol. El hecho de quedarte en Dart y poder cruzar a los flujos nativos del sistema sin cambiar de herramienta pesa mucho cuando la app tiene permisos, pagos o login biométrico de por medio, que es casi siempre.
Maestro entra cuando el objetivo es otro: flujos de humo rápidos que vigilen lo crítico en cada despliegue, una suite que mantenga QA sin depender del equipo de desarrollo, o pruebas que tengan que funcionar sobre varios stacks. No son excluyentes: hemos visto equipos usar Maestro para el humo diario en CI y Patrol para los recorridos profundos que tocan el sistema. Lo que no recomendamos es decidir por moda. Decide por quién va a escribir y mantener los tests, y por si necesitas llegar al interior de la app.
Si estás montando la automatización de tu app Flutter y no quieres descubrir a mitad de camino que elegiste la herramienta por el motivo equivocado, en Dribba llevamos quince años con equipo senior in-house metidos en esto. Cuéntanos cómo está tu suite y te decimos por dónde empezar.
