Waits y sincronización: reemplazando Thread.sleep por WebDriverWait en Appium
5 Thread.sleep eliminados, WebDriverWait con ExpectedConditions, un error de driver duplicado y comparación de tiempos. 4 tests, 0 sleeps.
Registros en “Appium”
Appium + Java + Android: framework de mobile automation construido desde cero con Page Object Model, BaseTest, WebDriverWait, W3C Actions, WebView con cambio de contexto, permisos del sistema, DataProviders, Allure Reports y CI/CD con GitHub Actions corriendo en emulador Android. Cada decisión documentada contra Sauce Labs My Demo App.
Interacciones básicas: tap, input, scroll y assertions en Appium
Login completo, scroll con UiScrollable, clear con reingreso y campos vacíos. Cuatro tests, cinco errores reales resueltos. Thread.sleep incluido.
Appium Inspector: encontrar elementos en la app con dispositivo físico
Motorola G51 por USB en vez de emulador. Appium Inspector para explorar elementos, locators de Products y Login. Dos errores reales resueltos.
Primer test: abrir la app en el emulador con Appium
Proyecto Maven, conflicto Selenium/java-client con ContextAware resuelto, timeouts para 8GB RAM. Primer test verde abriendo la app en el emulador.
Setup completo: Node.js, Android Studio, Appium Server y emulador
Node.js, Android Studio, SDK, variables de entorno, emulador Pixel 8, Appium 3.3.1, UiAutomator2. Setup paso a paso con errores reales en 8GB RAM.
Appium: decisiones técnicas para mobile automation
Appium vs Maestro vs Espresso. Por qué Java, por qué Android primero. Análisis de mercado LATAM y decisiones técnicas para automation mobile.