Pruebas de navegación entre pantallas con XCUITest

Contenido del curso

Introducción al Testing en iOS

1
Testing en Swift más allá del 100% de cobertura
01:44 min

Unit Testing con XCTest

Integration testing

UI Testing con SwiftUI y XCTest

Reporte y Optimización de Calidad

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:39

Pruebas de navegación entre pantallas con XCUITest

Curso de Swift Unit Testing

Clase 13 de 15

Clase 13 / 15

Comentarios (1)1 comentarios

Sergio Baudilio Pinilla Martinez

Hace 2 años

Hola profe, hay forma de agregar un tiempo de espera sin necesidad de realizar un assert , es decir si un boton llamara un web service que demora 2 segundos y luego quiero validar un elemento que se pinta de ese llamado como se podria hacer ?

Tiago Moreno

Team Platzi

Hace 2 años

La forma correcta de hacerlo es usar expectations con waitForExpectations(timeout:) y que tu funcion tenga un completion para informar que recibio una respuesta del servidor.

func testEsperaSinAssert() {
    let expectation = expectation(description: "Esperar a que el servicio responda")
    
    funcionAsyncrona {
        expectation.fulfill() // Se cumple la expectativa despues de tener respuesta
    }
    
    waitForExpectations(timeout: 3) // Espera hasta 3 segundos antes de fallar
}

Recursos

Probar la navegación entre pantallas en iOS requiere algo más que validar elementos estáticos. Cuando trabajas con XCUITest y flujos que abren sheets o navegan a vistas de detalle, necesitas manejar transiciones, predicados y tiempos de espera. Esta guía te muestra cómo escribir pruebas de UI para flujos dinámicos en una app iOS, ideal para desarrolladores que ya dominan los tests básicos y quieren llevar su cobertura al siguiente nivel.

¿Cómo pruebo la apertura de un formulario modal en XCUITest?

El primer flujo a cubrir es el de levantar un formulario para agregar un nuevo registro. Dentro de HomeViewUITest se crea una función llamada testAddRecord que valida la existencia del botón antes de interactuar con él [00:18].

El patrón es simple pero estricto:

Validar que el botón existe con XCTAssertTrue(addRecordButton.exists).
Ejecutar la acción con addRecordButton.tap().
Verificar que un elemento de la siguiente pantalla aparezca tras la transición.

Aquí aparece el primer detalle técnico importante. Como hay una transición visual entre el tap y la aparición del sheet, no puedes usar .exists directamente. La pantalla todavía no terminó de renderizarse cuando tu test ya está preguntando si existe el elemento.

¿Qué es waitForExistence en XCUITest? Es un método que espera hasta que un elemento aparezca en la UI dentro de un timeout definido. Si el elemento no aparece en ese tiempo, el test falla. Es la forma correcta de manejar transiciones asíncronas entre pantallas.

Por eso se usa newRecordSheet.waitForExistence(timeout: 3), donde newRecordSheet apunta al staticTexts["formRecordTitle"] de la siguiente pantalla [01:20]. Tres segundos es un margen amplio que evita falsos negativos por lentitud del simulador.

¿Cómo busco elementos dinámicos con predicados en XCUITest?

El segundo flujo es más interesante: navegar al detalle de un registro existente. El reto es que los registros se generan dinámicamente, así que no puedes usar un identificador fijo. Aquí entra el concepto de mock data, configurado previamente para garantizar que la vista siempre tenga registros durante las pruebas de UI [02:30].

La solución es construir una query con NSPredicate. En lugar de buscar un identificador exacto, buscas cualquier botón cuyo identificador empiece con un patrón conocido:

swift let firstRecord = app.buttons.matching( NSPredicate(format: "identifier BEGINSWITH 'record_'") ).firstMatch

La función matching filtra todos los botones que cumplen el predicado y devuelve una colección. Con .firstMatch obtienes el primer elemento que coincide, sin importar su ID específico [03:15].

¿Para qué sirve firstMatch en pruebas de UI? Devuelve el primer elemento que coincide con un predicado o consulta. Es útil cuando trabajas con listas dinámicas y solo necesitas interactuar con un elemento representativo, no con uno específico.

El flujo completo del test queda así:

Construir el predicado con BEGINSWITH 'record_'.
Obtener el primer match y validar su existencia con XCTAssertTrue.
Hacer tap sobre el registro.
Validar que un elemento de la vista de detalle aparezca, por ejemplo el botón de eliminar.

¿Por qué necesito waitForExistence al navegar entre pantallas?

Al revisar el código de detalle, aparece el mismo error sutil que en el primer test. Validar la vista de detalle con .exists falla porque la transición de navegación toma tiempo. La corrección consiste en reemplazar detailView.exists por detailView.waitForExistence(timeout: 3) [04:40].

La regla práctica es clara: cualquier validación posterior a una transición de pantalla debe usar waitForExistence. Esto incluye:

Apertura de sheets o modales.
Navegación push a vistas de detalle.
Cambios de tab que recargan contenido.
Animaciones que retrasan el render de elementos.

Usar .exists en estos casos genera tests inestables, los famosos flaky tests que pasan en local y fallan en CI sin razón aparente.

Habilidades y conceptos que se trabajan en esta clase

A lo largo del ejercicio se ponen en práctica varias habilidades clave del UI testing en iOS:

XCTAssertTrue: aserción que valida que una condición booleana sea verdadera. Es la base de las verificaciones en cada paso del test [00:45].
NSPredicate con BEGINSWITH: técnica para construir consultas flexibles sobre identificadores dinámicos, útil cuando los IDs incluyen sufijos variables como un UUID [03:00].
firstMatch: propiedad que extrae el primer elemento de una colección filtrada por matching, ideal para listas generadas en tiempo de ejecución [03:20].
waitForExistence(timeout:): método que espera hasta que un elemento exista dentro de un tiempo máximo, fundamental para flujos con transiciones [01:25].
Mock data en UI testing: estrategia de inyectar datos de prueba para garantizar que la UI tenga contenido predecible durante los tests [02:35].

Con estos cuatro pilares cubres la mayoría de escenarios de navegación en una app iOS estándar. El reporte final del test runner muestra todos los casos en verde: apertura del sheet, selección de filtro, validación de elementos en la UI y navegación al detalle [05:30].

Quedan vistas pendientes por cubrir en la app. Implementa los tests faltantes siguiendo este mismo patrón y cuéntame en los comentarios qué predicados usaste y cómo manejaste las transiciones más complicadas.

func testEsperaSinAssert() {
    let expectation = expectation(description: "Esperar a que el servicio responda")
    
    funcionAsyncrona {
        expectation.fulfill() // Se cumple la expectativa despues de tener respuesta
    }
    
    waitForExpectations(timeout: 3) // Espera hasta 3 segundos antes de fallar
}

Resumen

¿Cómo pruebo la apertura de un formulario modal en XCUITest?

El patrón es simple pero estricto:

Validar que el botón existe con XCTAssertTrue(addRecordButton.exists).
Ejecutar la acción con addRecordButton.tap().
Verificar que un elemento de la siguiente pantalla aparezca tras la transición.

¿Qué es waitForExistence en XCUITest? Es un método que espera hasta que un elemento aparezca en la UI dentro de un timeout definido. Si el elemento no aparece en ese tiempo, el test falla. Es la forma correcta de manejar transiciones asíncronas entre pantallas.

¿Cómo busco elementos dinámicos con predicados en XCUITest?

La solución es construir una query con NSPredicate. En lugar de buscar un identificador exacto, buscas cualquier botón cuyo identificador empiece con un patrón conocido:

swift let firstRecord = app.buttons.matching( NSPredicate(format: "identifier BEGINSWITH 'record_'") ).firstMatch

La función matching filtra todos los botones que cumplen el predicado y devuelve una colección. Con .firstMatch obtienes el primer elemento que coincide, sin importar su ID específico [03:15].

¿Para qué sirve firstMatch en pruebas de UI? Devuelve el primer elemento que coincide con un predicado o consulta. Es útil cuando trabajas con listas dinámicas y solo necesitas interactuar con un elemento representativo, no con uno específico.

El flujo completo del test queda así:

Construir el predicado con BEGINSWITH 'record_'.
Obtener el primer match y validar su existencia con XCTAssertTrue.
Hacer tap sobre el registro.
Validar que un elemento de la vista de detalle aparezca, por ejemplo el botón de eliminar.

¿Por qué necesito waitForExistence al navegar entre pantallas?

La regla práctica es clara: cualquier validación posterior a una transición de pantalla debe usar waitForExistence. Esto incluye:

Apertura de sheets o modales.
Navegación push a vistas de detalle.
Cambios de tab que recargan contenido.
Animaciones que retrasan el render de elementos.

Usar .exists en estos casos genera tests inestables, los famosos flaky tests que pasan en local y fallan en CI sin razón aparente.

Habilidades y conceptos que se trabajan en esta clase

A lo largo del ejercicio se ponen en práctica varias habilidades clave del UI testing en iOS:

XCTAssertTrue: aserción que valida que una condición booleana sea verdadera. Es la base de las verificaciones en cada paso del test [00:45].
NSPredicate con BEGINSWITH: técnica para construir consultas flexibles sobre identificadores dinámicos, útil cuando los IDs incluyen sufijos variables como un UUID [03:00].
firstMatch: propiedad que extrae el primer elemento de una colección filtrada por matching, ideal para listas generadas en tiempo de ejecución [03:20].
waitForExistence(timeout:): método que espera hasta que un elemento exista dentro de un tiempo máximo, fundamental para flujos con transiciones [01:25].
Mock data en UI testing: estrategia de inyectar datos de prueba para garantizar que la UI tenga contenido predecible durante los tests [02:35].

Introducción al Testing en iOS

Testing en Swift más allá del 100% de cobertura

Unit Testing con XCTest

Pruebas Unitarias con XC Test en Desarrollo de Apps SWIFT

Tests asíncronos con XCTest en Swift

Pruebas Unitarias para View Models en Swift

Testing de Software: Estrategias y Configuración en Xcode

Mocks y stubs para unit tests en Swift

Pruebas Unitarias en Home View Model: Implementación y Validación

Integration testing

Pruebas de integración con SwiftData y ViewModel

Pruebas unitarias del SDDatabaseService en Swift Data

UI Testing con SwiftUI y XCTest

Qué es UI Testing en iOS con XCTest

Preparación de Proyectos para UI Testing en iOS

Pruebas de Interfaz de Usuario: Validación y Simulación de Eventos

Pruebas de navegación entre pantallas con XCUITest

Reporte y Optimización de Calidad

Code coverage en Xcode paso a paso

Estrategias Avanzadas de Testing en Desarrollo de Software

Pruebas de navegación entre pantallas con XCUITest

Progreso del curso

Introducción al Testing en iOS

Unit Testing con XCTest

Integration testing

UI Testing con SwiftUI y XCTest

Reporte y Optimización de Calidad

Recursos

Recursos