Appium: decisiones técnicas para mobile automation

Contexto: por qué mobile

Este post abre una nueva serie: mobile automation con Appium + Java + Android. Este post es contexto y decisiones. El código arranca en el Post 2.

Construí un framework web con Selenium + Java. Funciona, tiene 96 tests, CI/CD, reportes en GitHub Pages. Pero el mercado pide más.

Busqué ofertas de QA Automation en Argentina + remoto (mayo 2026). Lo que veo: Selenium sigue dominando web, pero un porcentaje creciente de las ofertas pide experiencia en mobile. Appium aparece en las descripciones junto a Selenium como combo. No como reemplazo: como complemento.

Empresas como Stefanini, Apply Digital, Coderio, Truelogic — todas buscando QA con Selenium + Appium + Java en LATAM. La señal es clara.

Sumo Appium porque el mercado lo exige como complemento de Selenium/Playwright.

Qué es Appium

Appium es un framework open source para automatizar apps móviles. Nativas, híbridas y web mobile. Funciona con Android e iOS.

La arquitectura es cliente-servidor:

[ Tu test en Java ]
        ↓
[ Appium Server (Node.js) ]
        ↓
[ Driver: UiAutomator2 (Android) ]
        ↓
[ Dispositivo / Emulador ]
        ↓
[ La app ]

Tu test habla con el Appium Server usando el protocolo W3C WebDriver (el mismo que usa Selenium). El server traduce esos comandos al driver de la plataforma — en Android, ese driver es UiAutomator2. El driver interactúa con la app.

Si venís de Selenium esto debería sonar familiar: es el mismo concepto. En Selenium tu test habla con ChromeDriver que controla Chrome. En Appium tu test habla con UiAutomator2 que controla la app en Android.

Appium 1.x vs Appium 2.x/3.x

Appium tuvo un cambio arquitectural grande en la versión 2.0:

En Appium 1.x todo venía empaquetado: server + drivers + plugins en un solo paquete. Actualizar algo significaba actualizar todo.

Desde Appium 2.0 es modular: instalás el server por un lado y los drivers por otro. Cada driver se actualiza de forma independiente. La versión actual (mayo 2026) es 3.2.2, pero el concepto fundamental es el mismo que se introdujo en 2.0.

Los comandos de instalación reflejan esta separación:

# Instalar Appium Server
npm install -g appium

# Instalar el driver para Android
appium driver install uiautomator2

Si leés tutoriales viejos que usan DesiredCapabilities sin el prefijo appium:, están en Appium 1.x. En esta serie usamos la versión actual con el estándar W3C.

Decisiones técnicas

Por qué Appium (y no Maestro, Espresso o Detox)

Voy a cubrir varias herramientas en el blog. Appium es el punto de partida.

Appium vs Maestro

La analogía que me funciona: Appium es el Selenium de mobile, Maestro es el Playwright.

Appium existe desde 2013. Más complejo de configurar, más maduro, multi-lenguaje (Java, Python, JavaScript, C#, Ruby). Maestro es de 2022, configuración mínima, tests escritos en YAML — no necesitás saber programar.

Maestro es más rápido para arrancar. Pero:

Busqué "Appium" en ofertas de trabajo: aparece constantemente. Busqué "Maestro mobile testing": casi no aparece. El mercado global tiene más de 1.400 ofertas mencionando Appium. Maestro es una fracción de eso.

Appium tiene más de 9.800 empresas usándolo globalmente. Maestro está creciendo, pero hoy la adopción empresarial no se compara.

El dato que cerró mi decisión: en las ofertas de QA LATAM que revisé (Stefanini, Coderio, Apply Digital, Truelogic), todas mencionan Appium. Ninguna menciona Maestro.

Maestro va a aparecer en el Post 17 de esta serie como comparación directa. Pero para empleabilidad hoy: Appium.

Appium vs Espresso

Espresso es el framework nativo de Google para Android. Es rápido, estable, integrado en Android Studio.

El problema: solo sirve para Android, y generalmente lo usan los developers, no los QAs. Las ofertas piden "Espresso" como un plus, no como el skill principal. Además, requiere acceso al código fuente de la app — algo que como QA externo no siempre tenés.

Appium no necesita el código fuente. Testeás la app como la ve el usuario: con el .apk instalado.

Appium vs Detox

Detox es específico para React Native. Si la app no es React Native, no sirve. Appium es agnóstico al framework con el que fue construida la app.

Tabla resumen:

Por qué Java

Misma razón que en mi serie Selenium: demanda del mercado en LATAM.

Las ofertas de mobile automation en LATAM piden mayoritariamente Java. Algunas piden Python, algunas JavaScript. Pero Java + Appium sigue siendo el combo más solicitado.

Además, ya tengo el stack montado: Java 17, Maven, TestNG, IntelliJ, Allure. Todo eso se reutiliza. El client library de Appium para Java (java-client) se integra directo con lo que ya conozco.

No voy a aprender un lenguaje nuevo para esta serie. Voy a profundizar en el que ya tengo y sumarle mobile.

Por qué Android primero

Dos razones:

1. Estoy en Windows. Para automatizar iOS necesitás macOS + Xcode + simulador de iPhone. Sin Mac, iOS no es opción real.
2. Android tiene más demanda en LATAM. La fragmentación de dispositivos (más de 24.000 modelos Android distintos en el mercado) hace que las empresas necesiten más automation en Android que en iOS.

Android tiene otra ventaja: todo el tooling es gratuito. Android Studio, el emulador, las SDK tools. No hay barreras de entrada.

Si en algún momento consigo acceso a una Mac, sumo iOS a la serie. Por ahora: Android.

App target: Sauce Labs My Demo App

Para testear necesito una app. No puedo usar demo.serenity.is porque es una app web — Appium es para apps nativas.

Elegí la Sauce Labs My Demo App (Android). Es una app nativa construida por el equipo de Sauce Labs específicamente para practicar automation. El .apk se descarga gratis desde su repo en GitHub:

github.com/saucelabs/my-demo-app-android

Qué tiene la app:

• Login con usuarios
• Catálogo de productos con imágenes y precios
• Carrito de compras
• Checkout completo
• Swipe entre productos
• QR code scanner
• Menú de navegación

Son suficientes features para cubrir los 17 posts de la serie sin quedarme corto. Tiene login para practicar inputs, catálogo para practicar scroll y selección, checkout para practicar flujos completos.

Y al ser de Sauce Labs, está mantenida y es la que más se usa en tutoriales y cursos serios de Appium.

Setup: emulador vs dispositivo físico

Tengo dos opciones para correr los tests:

Emulador Android (Android Studio): un dispositivo virtual que corre en mi máquina. Es lo que se usa en CI/CD y en la mayoría de empresas para desarrollo.

Dispositivo físico (mi Motorola G51 5G): conectado por USB. Más rápido, sin consumo extra de RAM, testeo en hardware real.

8GB de RAM es una restricción común en equipos de QA en LATAM. Documentar cómo se trabaja con eso es parte del valor de la serie.

Mi plan:

• Posts 2-7: setup y tests con emulador. Quiero documentar el proceso completo, incluyendo los problemas de RAM. Eso es lo que vas a encontrar en un trabajo real.
• Post 8: conecto el Motorola G51 por USB y documento la alternativa.
• CI/CD (Post 15): emulador en la nube vía GitHub Actions.

El emulador va primero porque es lo que el mercado espera que sepas usar. El dispositivo físico es un complemento.

Repo

A diferencia de la serie Selenium (que vive dentro de selenium-java-framework), esta serie tiene repo propio:

appium-mobile-testing/
├── src/
│   ├── main/java/
│   └── test/java/
├── apk/
├── pom.xml
└── README.md

El repo va a crecer a medida que avance la serie. La estructura final la defino cuando llegue al Post 13 (refactorización). Por ahora: lo mínimo para arrancar.

Repo: github.com/cesarbeassuarez/appium-mobile-testing

Qué viene en esta serie

17 posts. Desde setup hasta CI/CD con GitHub Actions y comparación final con Maestro.

El recorrido:

• Posts 1-3: decisiones, setup completo, primer test
• Posts 4-6: Appium Inspector, interacciones básicas, waits
• Posts 7-8: Page Object Model, dispositivo físico
• Posts 9-11: gestos, permisos y deep links, lifecycle y resiliencia de red
• Posts 12-14: WebViews, data-driven testing, refactorización del framework
• Posts 15-16: CI/CD con GitHub Actions, Allure Reports en GitHub Pages
• Post 17: Appium vs Maestro

Misma filosofía que mis series anteriores: decisiones con contexto de mercado y problemas reales documentados.

Estado actual

Herramienta elegida (Appium), lenguaje elegido (Java), plataforma elegida (Android), app target elegida (Sauce Labs My Demo App), repo definido.

Sin código todavía. Sin nada instalado.

Próximo post: instalar todo. Java 17, Node.js, Appium Server, Android Studio, emulador, UiAutomator2. Las "3 cosas que hay que sincronizar" para que Appium funcione.