Te comparto acá algunas lecciones aprendidas de un proyecto en el que estuvimos automatizando con Appium una aplicación mobile, tanto para Android como para iOS. ¡Gracias Alexis Álvarez por compartir!
Las bases automatizando con Appium
Appium es un framework de automatización de pruebas de código abierto para probar aplicaciones nativas e híbridas y aplicaciones web móviles. Se maneja iOS y Android usando el protocolo WebDriver. Esto significa, que si ya automatizás en Selenium, va a ser muy fácil que aprendas a usar Appium.
El Framework
Utilizamos las siguientes tecnologías:
- Java v1.8
- Appium v1.6.4
- TestNG v6.11
- XCode v8.2.1
- Android Studio v2.3.0
- Genymotion v2.9.0 (Emulador Android)
- Maven v3.3.9
- Allure v2.6 (Reportes)
Emuladores
Mac OS: Utilizamos xCode por defecto ya que cuenta con todos los tipos de devices que se pueden necesitar.
Android: Preferimos el uso de Genymotion ya que notamos mejor performance con respecto al emulador nativo (Android Studio).
Inconvenientes de Appium en iOS
- En iOS, sólo se puede ejecutar una prueba a la vez por Mac.
- Nativamente no soporta el uso de Locations. Esto lo estuvimos investigando y no lo resolvimos aún, lo más cercano fue utilzando “osascript” pero no funcionó ya que si bien seteaba el location, el simulador no lo tomaba (ver esta discusión).
Otros inconvenientes generales de Appium
- La interacción con Google Maps puede llegar a ser un poco tediosa, por los elementos dinámicos y hay que encontrar buenos locators. En Selenium también se tienen que hacer algunos trucos a veces.
- El uso de Webviews debe ser manejado con cuidado utilizando el cambio de “Contexts” (ver).
- Apoyo limitado a los gestos (por ejemplo: Scroll horizontal y/o vertical, para los cuales utilizamos la función de swipe y no la función scrollTo(), ya que no funciona).
- El set up lleva un tiempo considerable a tener en cuenta (promedio 4 horas).
Proyectos separados
Una decisión de diseño que tomamos desde el inicio, fue tener dos proyectos separados, por un lado las pruebas de Appium y por otro las de iOS. Esto fue por varios motivos:
- Si bien las aplicaciones se ven igual en ambos sistemas operativos, el código es distinto, las aplicaciones son distintas.
- Las dos aplicaciones son desarrolladas por distintos equipos, distintas personas que usan distintas herramientas.
- Los equipos desarrollan a distintos tiempos. Algunas funcionalidades salen primero en una plataforma que en otra.
Otros aspectos de diseño
Puntos a tener en cuenta al momento de desarrollar el framework:
- No dejar datos en el código de pruebas. Utilizar Data Sets y archivos de properties.
- Se recomienda el uso de Test Suites, utilizando las notaciones de TestNG para esto.
- Organización de Pruebas utilizando notaciones de Test Groups de TestNG.
- Para apuntar a la mantenibilidad de las pruebas, utilizar el patrón Page object tal como se suele hacer en pruebas web con Selenium.
- Los Locators presentan el mismo desafío que en web. Localizar elementos por ID o resource ID es lo ideal. Si la aplicación no cuenta con los mismos, es aconsejable pedir ayuda a un desarrollador para que los agregue, realmente hace una diferencia enorme en mantenibilidad y entendimiento de las pruebas.
Cerrando
Más allá de los aspectos técnicos mencionados, para garantizar el éxito, lo más importante es el involucramiento de la gente. Por suerte en este proyecto todo el equipo se vio motivado. Realizamos algunos talleres para facilitar la curva de aprendizaje, y así tener al equipo de desarrollo con el ownership de la tarea de automatizar las próximas pruebas de las funcionalidades nuevas.
El siguiente objetivo será incorporar BDD en la metodología de trabajo, y atacar la deuda técnica, o sea, automatizar las pruebas de las funcionalidades ya desarrolladas.