Automatización de aplicaciones móviles con Appium

Sí, para ambos, y esa es una de sus grandes ventajas: permite escribir pruebas con el mismo estilo y el mismo protocolo estándar para las dos plataformas. La clave es que Appium usa drivers distintos para cada una —UiAutomator2 para Android y XCUITest para iOS— que traducen los comandos estándar al lenguaje de automatización nativo de cada sistema. En la práctica, aunque el estilo de la prueba se comparte, cubrir las dos plataformas se parece a mantener dos suites, porque el comportamiento, los identificadores y los requisitos difieren. Además, automatizar iOS tiene un requisito ineludible: solo puede hacerse desde una máquina con macOS y las herramientas de Apple, algo que conviene tener en cuenta al planificar antes de empezar.

Son las extensiones que le permiten a Appium comunicarse con cada plataforma, y son el centro de su arquitectura. Appium por sí solo no sabe hablar con ningún teléfono: funciona como un coordinador que recibe comandos siguiendo el protocolo estándar WebDriver y los reparte al driver adecuado, que sabe traducirlos al lenguaje de automatización nativo de una plataforma concreta. UiAutomator2 hace esa traducción para Android y XCUITest para iOS. En la versión 2 de Appium, los drivers se instalan por separado y a demanda con la interfaz de línea de comandos, en lugar de venir todos incluidos, así que antes de escribir una prueba hay que instalar el driver de la plataforma que se va a automatizar. Esa separación entre el protocolo estándar, que es único, y la traducción específica, que vive en los drivers, es lo que hace flexible a la herramienta.

Son el conjunto de datos que se le pasa a Appium al iniciar una sesión para describir qué se va a automatizar y dónde: la plataforma, el driver que hay que usar, el dispositivo o emulador de destino y la aplicación bajo prueba, entre otros. Definen el qué y el dónde de la automatización, mientras que el cuerpo de la prueba define el cómo. Su utilidad práctica es que cambiar de un emulador a un dispositivo real, o de una versión de la aplicación a otra, suele resolverse cambiando capacidades sin tocar la lógica de la prueba. Por eso conviene mantener las capacidades separadas y parametrizables, de la misma forma que las variables de entorno en las pruebas de API, para que la misma prueba corra en distintos dispositivos y configuraciones.

Porque el entorno móvil suma capas de complejidad que en web no existen. Hay dos sistemas operativos distintos con comportamientos propios; una enorme fragmentación de dispositivos, tamaños de pantalla y versiones, sobre todo en Android, de modo que lo que funciona en un aparato puede fallar en otro; diálogos del sistema que interrumpen la prueba, como los de permisos, actualizaciones o notificaciones; y gestos y animaciones que introducen tiempos variables. Todo eso hace que las pruebas que a veces pasan y a veces fallan sean el problema número uno de la automatización móvil. La forma de combatirlo es diseñar para la estabilidad: usar identificadores robustos, esperar por condiciones concretas en lugar de por tiempos fijos, contemplar los diálogos del sistema y aislar bien cada prueba, temas que se desarrollan en la guía sobre pruebas inestables.

Usando identificadores que quien desarrolla asigna a propósito, y no características que cambian con facilidad. La estrategia más recomendada es el identificador de accesibilidad, pensado tanto para la automatización como para las herramientas de accesibilidad, que es estable entre versiones y puede compartirse entre Android e iOS. También son estables el identificador de recurso en Android y el nombre en iOS, aunque son específicos de cada plataforma. Lo que conviene evitar es localizar por el texto visible, que cambia con el idioma, o por la posición del elemento en la jerarquía de la pantalla, que cambia con cualquier rediseño. Como esos identificadores los pone quien desarrolla, conseguir pruebas estables depende de una colaboración con el equipo de desarrollo: pedir buenos identificadores es parte del trabajo de automatización.

No. En móvil, el costo de crear y mantener pruebas automatizadas es más alto que en web por toda la complejidad del entorno, así que automatizarlo todo no es rentable. La estrategia sensata es automatizar lo que más lo justifica: los flujos críticos del negocio, las pruebas de regresión que hay que repetir con cada versión, y los caminos estables que no cambian seguido. Para lo demás —exploración, validación de experiencia de uso, comprobaciones sobre dispositivos o situaciones poco frecuentes— suele rendir más el testing manual. Esa decisión de qué automatizar y qué dejar a mano forma parte de la estrategia de pruebas del proyecto, que pondera el riesgo, la frecuencia de ejecución y el costo de mantenimiento de cada prueba antes de invertir en automatizarla.