Tests de UI con XCUITest: cuándo compensan y por qué son frágiles

XCUITest no es una prueba unitaria grande: es una arquitectura distinta. El proceso de pruebas no habla con tus objetos sino que le pide al sistema que manipule otra aplicación, y cada consulta viaja hasta el árbol de accesibilidad de un proceso que mientras tanto sigue animando, cargando y recomponiendo vistas. De ese hecho se derivan sus dos propiedades esenciales, que conviene aceptar juntas: es la única capa capaz de responder a la pregunta de si la app arranca y se puede usar, y es una capa donde toda afirmación es una carrera contra el tiempo. Quien intenta escribir con ella la suite entera acaba con cuarenta minutos de ejecución y un equipo que reejecuta ante cualquier rojo.

Lo que solo esta capa puede verificar

La pregunta útil no es si las pruebas de interfaz son buenas o malas, sino qué defectos existen que ninguna otra prueba puede detectar. La lista es corta y por eso mismo valiosa: que la app arranca sin fallar con el paquete real y sus recursos; que la navegación completa lleva del inicio al objetivo sin callejones sin salida; que el flujo de compra, alta o pago funciona de punta a punta; que la integración entre módulos que nadie prueba junta se sostiene; y que un cambio en el sistema no ha roto un permiso o una hoja del sistema. Todo lo demás —reglas, formatos, cálculos, estados de error— se comprueba más rápido y con más fiabilidad una capa por debajo.

De ahí sale la regla de presupuesto que sostienen los equipos que conviven bien con esta herramienta: un puñado de recorridos críticos, no una matriz de casos. Cinco pruebas que cubren los caminos por los que pasa el noventa por ciento de los usuarios valen más que ochenta que exploran variantes de un formulario, porque las ochenta tardan media hora, fallan por su cuenta cada semana y verifican cosas que un test de lógica clava en un milisegundo.

El identificador de accesibilidad es el contrato

Buscar un elemento por su texto visible ata la prueba a dos cosas que cambian solas: la redacción y el idioma. El identificador de accesibilidad existe justamente para dar a cada elemento un nombre estable que no se muestra al usuario ni se traduce, y usarlo convierte la interfaz en una superficie con contrato.

// En la vista: el nombre estable va aparte del texto visible.
Button("Guardar cambios") { modelo.guardar() }
    .accessibilityIdentifier("perfil.boton.guardar")

List(modelo.tareas) { tarea in
    TareaFila(tarea: tarea)
        .accessibilityIdentifier("tareas.fila.\(tarea.id)")
}

// En la prueba: un objeto de pantalla concentra los selectores.
struct PantallaPerfil {
    let app: XCUIApplication

    var guardar: XCUIElement { app.buttons["perfil.boton.guardar"] }
    var aviso: XCUIElement { app.staticTexts["perfil.texto.aviso"] }

    @discardableResult
    func pulsarGuardar() -> Self {
        XCTAssertTrue(guardar.waitForExistence(timeout: 5))
        guardar.tap()
        return self
    }
}

El objeto de pantalla no es ceremonia: es lo que impide que renombrar un identificador obligue a editar treinta ficheros. Toda consulta vive en un solo sitio, las pruebas quedan escritas en el vocabulario del producto y el mantenimiento se concentra donde debe. La convención de nombres —pantalla, tipo de elemento, propósito— importa menos que el hecho de tener una, porque un espacio de nombres plano acaba con dos botones llamados guardar en pantallas distintas y con una prueba que pulsa el equivocado.

La fragilidad es asíncrona y se administra

La inestabilidad de esta capa tiene tres orígenes, y cada uno admite un remedio distinto. El primero es el estado previo: si la app conserva sesión, base de datos o preferencias entre casos, el orden de ejecución decide el resultado. El remedio es sembrar la app desde el lanzamiento y hacer que la propia app entienda esos argumentos.

final class CompraTests: XCTestCase {
    private var app: XCUIApplication!

    override func setUp() {
        continueAfterFailure = false
        app = XCUIApplication()
        app.launchArguments = ["-modoPruebas", "-almacenLimpio", "-sinAnimaciones"]
        app.launchEnvironment = ["SESION": "usuario.demo", "CATALOGO": "fijo"]
        app.launch()
    }
}

// En la app, una unica puerta para el modo de pruebas.
@main struct MiApp: App {
    init() {
        if ProcessInfo.processInfo.arguments.contains("-sinAnimaciones") {
            UIView.setAnimationsEnabled(false)
        }
    }
}

El segundo origen es el tiempo: la prueba consulta un elemento que aún no ha aparecido porque hay una animación en curso o una carga pendiente. La respuesta correcta nunca es una espera fija, sino una espera sobre la condición concreta, con waitForExistence o con una expectativa sobre un predicado, y con un mensaje que diga qué se estaba esperando. Desactivar las animaciones en modo de pruebas elimina de golpe una fracción grande de estas carreras, y sustituir el servidor real por respuestas locales elimina otra.

El tercero es el sistema: diálogos de permisos, teclados que aparecen tapando el botón, hojas de compartir y alertas del sistema operativo que interrumpen el flujo. Aquí la herramienta es el monitor de interrupciones, que registra un manejador para cuando aparezca una alerta ajena, y la disciplina de conceder permisos por adelantado en la configuración del simulador siempre que sea posible.

addUIInterruptionMonitor(withDescription: "Permiso de notificaciones") { alerta in
    let permitir = alerta.buttons["Permitir"]
    guard permitir.exists else { return false }
    permitir.tap()
    return true
}
app.tap()   // el monitor solo se dispara al interactuar con la app

Ese último toque desconcierta a todo el mundo la primera vez: el manejador no se ejecuta cuando aparece la alerta sino cuando la prueba intenta interactuar con la aplicación y encuentra la interrupción por delante. Y como el texto del botón pertenece al sistema operativo y está traducido, esta es la única situación donde buscar por texto es inevitable; la salida limpia consiste en fijar el idioma del simulador desde los argumentos de lanzamiento para que ese texto sea predecible.

flowchart TB
f[Prueba de interfaz inestable] --> a[La causa es estado previo]
a --> a1[Sembrar datos al lanzar y limpiar el almacen]
f --> b[La causa es sincronizacion]
b --> b1[Esperas por condicion con tiempo limite]
b --> b2[Desactivar animaciones en modo pruebas]
b --> b3[Respuestas de red locales y deterministas]
f --> c[La causa es el sistema operativo]
c --> c1[Monitor de interrupciones para alertas]
c --> c2[Permisos concedidos antes de lanzar]
a1 --> v[Prueba repetible]
b1 --> v
b2 --> v
b3 --> v
c1 --> v
c2 --> v