Maestro - framework de pruebas automatizadas de UI para apps móviles

• La forma más fácil de automatizar las pruebas de UI de apps móviles
• Tiene tolerancia intrínseca a la inestabilidad de los elementos de UI
  • Como los elementos de UI no siempre están en la posición esperada, tocar la pantalla no siempre funciona
  • Busca aceptar y responder a la inestabilidad de las aplicaciones móviles y de los dispositivos
• Tiene tolerancia intrínseca a los retrasos
  • No hace falta poner llamadas a sleep() en las pruebas
  • Sabe que la carga de contenido (por ejemplo, por red) puede tardar y espera automáticamente, pero no más de lo necesario
• Permite una iteración muy rápida
  • Las pruebas se interpretan, así que no hace falta compilarlas
  • Puede monitorear continuamente los archivos de prueba y volver a ejecutarlos cuando cambian
• Ofrece una sintaxis declarativa pero potente
  • Las pruebas se definen en archivos yaml
• La configuración es simple
  • Es un binario único que funciona en cualquier parte

Opinión de GN⁺

• Maestro es una nueva herramienta para automatizar pruebas de apps móviles y busca superar las limitaciones de Appium, Espresso, UIAutomator y XCTest, entre otras. En particular, parece poder reducir problemas frecuentes de las herramientas existentes gracias a su tolerancia intrínseca a la inestabilidad de los elementos de UI y a los retrasos.
• Como usa una sintaxis declarativa basada en YAML, parece que incluso ingenieros de QA que no son desarrolladores podrían escribir casos de prueba con facilidad. Aun así, si no se está familiarizado con la sintaxis de YAML, puede haber un costo de aprendizaje.
• Appium es una herramienta ampliamente usada para la automatización de pruebas de apps móviles. Tiene la ventaja de soportar varias plataformas móviles y lenguajes de programación, pero también la desventaja de tener una alta tasa de fallas en pruebas por problemas de estabilidad. Habrá que ver hasta qué punto Maestro puede resolver estos problemas de Appium.
• Actualmente, Maestro cuenta con buena documentación y también opera una comunidad en Slack, por lo que vale la pena considerarlo para adopción. Aun así, como todavía es una versión temprana, parece necesario validarlo suficientemente antes de aplicarlo en entornos de producción.

[laeyoung]

Al probarlo, estuvo bastante bien porque se puede hacer rápido (desde la configuración hasta crear el primer YAML de prueba, en alrededor de 1 hora).

[rabolution]

Maestro es simple y tiene muchas cosas buenas. Pero en Android todavía hay un problema con la entrada de texto en coreano. https://github.com/mobile-dev-inc/maestro/issues/146

Otro punto decepcionante es que, en comparación con otras herramientas de testing, no se ejecuta rápido. Normalmente, como las herramientas de testing se ejecutan muy rápido a diferencia de un usuario real, había problemas de que las pruebas fallaran de forma flaky si no se diseñaba el wait con mucha precisión. Maestro es tan lento que hasta da la impresión de que lo resolvieron simplemente esperando lentamente. ^^;;;

[rabolution]

Por otro lado, en el testing de frontend web se ha vuelto popular un enfoque que aprovecha los elementos de accesibilidad, y en móvil también. (consulten https://blog.banksalad.com/tech/test-in-banksalad-ios-2/)

Como Maestro se centra principalmente en text e id, me resultó difícil distinguir los roles de link, button, heading, etc., para algo como "lista de productos". También se echa de menos que no se puedan validar aspectos que en web sí se pueden comprobar con aria-checked, aria-expanded, etc.

En mi caso, para evitar conflictos de id, terminaba agregando prefijos al test-id y, al final, resultaba engorroso tener que volver a probar si el elemento obtenido de esta forma realmente renderizaba el text esperado.

[smboy86]

Gracias por el comentario tan lleno de insights.