UI Automator: qué es, conceptos clave y cómo funciona

¿Qué es UI Automator?

UI Automator es un framework para pruebas funcionales de UI en Android que opera a nivel del sistema operativo. Proporciona una API para acceder a cualquier elemento en la pantalla del dispositivo, independientemente de a qué aplicación pertenezca — incluyendo la barra de estado del sistema, diálogos de permisos, la pantalla de inicio y aplicaciones de terceros. Esto lo hace indispensable para probar escenarios que van más allá de una sola aplicación.

Arquitectónicamente, UI Automator utiliza el Accessibility Service — el mismo servicio que usan TalkBack, Switch Access y otras herramientas de accesibilidad. A través de este servicio, el framework obtiene el árbol completo de componentes UI de la pantalla actual y permite realizar acciones sobre ellos: tocar, deslizar, ingresar texto y mantener pulsado.

UI Automator apareció por primera vez en Android 4.3 (API 18) y desde entonces ha sido parte de Android Testing Support Library como la herramienta oficial de Google para pruebas entre aplicaciones. En AndroidX Test está disponible como un artefacto separado androidx.test.uiautomator:uiautomator versión 2.3.0 (2024), que soporta todas las versiones de Android desde API 18.

Cómo funciona UI Automator

Principio de funcionamiento: UI Automator se basa en escanear el árbol de accesibilidad de la pantalla actual. Cuando se llama al método findObject(selector), el framework recorre la jerarquía de Views, encuentra el primer elemento que coincide con las condiciones de UiSelector y devuelve un UiObject — un proxy para interactuar con la View real.

Ciclo de vida de una prueba UI Automator

Una prueba típica de UI Automator comienza obteniendo una instancia de UiDevice, que representa el dispositivo físico. UiDevice proporciona métodos para encontrar elementos, gestionar pulsaciones de botones (Home, Back, Recent), rotar la pantalla y tomar capturas. Después de encontrar un elemento mediante UiSelector, se realizan acciones sobre el UiObject.

Ejemplo básico

En el siguiente ejemplo, la prueba abre la aplicación Settings, encuentra el elemento “Batería” por texto y lo toca. UI Automator no requiere lanzar una Activity — funciona con cualquier pantalla del dispositivo, incluyendo aplicaciones de terceros.

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

// Abrir pantalla de configuración
device.pressHome()
device.wait(Until.hasObject(UiSelector().text("Configuración")), 2000)

// Buscar el elemento "Batería" y tocar
val batteryItem = device.findObject(
    UiSelector().text("Batería")
)
batteryItem.clickAndWait(Until.newWindow(), 3000)

UiDevice y UiSelector: clases clave

UiDevice es la clase principal para interactuar con el dispositivo. Proporciona métodos para encontrar elementos, simular pulsaciones de botones físicos (Home, Back, Menu, Volume), gestionar la energía, tomar capturas de pantalla y esperar estados específicos de la pantalla. UiDevice se crea una vez por prueba y se reutiliza para todas las operaciones.

UiSelector es una API fluida para encontrar elementos UI. A diferencia de Espresso ViewMatchers, UiSelector no requiere compilación — las condiciones de búsqueda se forman mediante una cadena de métodos: text(), className(), description(), resourceId(), index(). Múltiples condiciones se combinan automáticamente mediante AND lógico.

Ejemplo de búsqueda con múltiples condiciones

Cuando hay varios elementos en la pantalla con el mismo texto, UiSelector permite combinar criterios: encontrar un contenedor por ID, luego dentro de él — un elemento por texto y clase. Esto garantiza la identificación única del componente deseado. El método childSelector reduce el alcance de la búsqueda a un contenedor específico, acelerando la navegación por el árbol de UI.

val scrollView = device.findObject(
    UiSelector().resourceId("android:id/list")
)

// Dentro de la lista, buscar el elemento con texto "Wi-Fi"
val wifiItem = scrollView.findObject(
    UiSelector().text("Wi-Fi")
wifiItem.click()

Pruebas entre aplicaciones con UI Automator

Las pruebas entre aplicaciones (cross-application) son la función principal por la que se elige UI Automator. El framework puede cambiar entre aplicaciones, probar el inicio de sesión OAuth a través del navegador, verificar diálogos del sistema (permisos, selector de aplicación) e interactuar con la barra de estado del sistema, el panel de notificaciones y la pantalla de bloqueo.

Prueba de inicio de sesión OAuth

Un escenario típico de prueba cross-app: la aplicación abre un navegador para autorización OAuth, el usuario ingresa su usuario y contraseña, y el navegador redirige de vuelta a la aplicación. UI Automator cambia entre procesos, encuentra los campos de entrada en el navegador, los completa y toca “Iniciar sesión”.

// Esperando que aparezca el navegador
device.wait(Until.hasObject(
    UiSelector().packageName("com.android.chrome")
), 5000)

// Buscando campo de entrada de email en el navegador
val emailField = device.findObject(
    UiSelector().className("android.widget.EditText").instance(0)
)
emailField.text = "user@example.com"

Verificación de diálogos del sistema

UI Automator puede verificar y cerrar diálogos del sistema — permisos de ubicación, notificaciones, acceso a archivos. Esto es críticamente importante para probar escenarios de primer inicio cuando el sistema solicita varios permisos secuencialmente. Sin UI Automator, estos escenarios no se pueden automatizar porque los diálogos del sistema no pertenecen al proceso de la aplicación.

UI Automator vs Espresso: comparación de enfoques

La elección entre UI Automator y Espresso depende del escenario de prueba. Espresso está optimizado para probar una sola aplicación con sincronización automática y mínimo boilerplate. UI Automator es adecuado para escenarios donde se necesita interactuar con el sistema, el navegador o múltiples aplicaciones.

En la práctica, estos frameworks se usan a menudo juntos: Espresso cubre las pruebas de UI de la aplicación principal con alta estabilidad, mientras que UI Automator se incorpora para escenarios que van más allá de los límites de la aplicación — inicio de sesión OAuth, permisos del sistema, trabajo con Share Intent. Esta combinación proporciona la máxima cobertura de UI con costos mínimos de mantenimiento de pruebas.

Configuración de UI Automator en un proyecto Android

La integración de UI Automator se realiza añadiendo una dependencia en build.gradle. El framework es parte de AndroidX Test y no requiere permisos adicionales en el manifiesto — el acceso al Accessibility Service se configura automáticamente al lanzar la prueba instrumentada.

Dependencias de Gradle

La configuración mínima incluye el artefacto uiautomator y el ejecutor de pruebas estándar AndroidJUnitRunner. Las pruebas de UI Automator se colocan en el directorio src/androidTest y se ejecutan en un emulador o dispositivo físico con Android API 18+.

dependencies {
    androidTestImplementation("androidx.test.uiautomator:uiautomator:2.3.0")
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
    androidTestImplementation("androidx.test:runner:1.6.1")
}

UiDevice y configuración de pruebas

Para obtener una instancia de UiDevice se usa InstrumentationRegistry.getInstrumentation(). UiDevice debe crearse una vez en el método setUp() y reutilizarse en todas las pruebas de la clase para conservar los recursos del dispositivo. Es importante tener en cuenta que UiDevice no es thread-safe — todas las operaciones deben ejecutarse en el mismo hilo del método de prueba. Crear un nuevo UiDevice en cada prueba genera sobrecarga y ralentiza la ejecución. Se recomienda crear UiDevice una vez en el método beforeClass y reutilizarlo para todas las pruebas de la clase.

Espera en UI Automator

A diferencia de Espresso, UI Automator no tiene sincronización automática. Para esperar la aparición de elementos se usa el método UiDevice.wait(condition, timeout) con un objeto Until: Until.findObject(selector), Until.hasObject(selector), Until.gone(selector). Sin esperas adecuadas, las pruebas se vuelven inestables debido a condiciones de carrera — un elemento puede no haber aparecido en la pantalla en el momento de la búsqueda. Se recomienda establecer un tiempo de espera de al menos 3–5 segundos para la estabilidad.