Preparación de Proyectos para UI Testing en iOS

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:008:31

Preparación de Proyectos para UI Testing en iOS

Curso de Swift Unit Testing

Clase 11 de 15

Clase 11 / 15

Recursos

La automatización de pruebas de UI es un componente esencial en el desarrollo de aplicaciones modernas, permitiendo verificar que la interfaz de usuario funcione correctamente antes de llegar a producción. En este artículo, exploraremos cómo preparar un proyecto Swift para realizar UI testing efectivo, configurando los elementos necesarios para identificar componentes visuales y automatizar interacciones con la interfaz.

¿Cómo preparar tu proyecto para UI testing?

Antes de comenzar con las pruebas de UI, es fundamental realizar algunas configuraciones previas en nuestro proyecto para hacerlo compatible con este tipo de testeo. Estas preparaciones nos permitirán identificar elementos visuales específicos y automatizar interacciones con ellos durante las pruebas.

¿Qué son los accessibility identifiers y por qué son importantes?

Los accessibility identifiers son identificadores únicos que asignamos a cada elemento visual que queremos probar en nuestra aplicación. Estos identificadores permiten que nuestros tests localicen elementos específicos en la interfaz para interactuar con ellos o verificar su presencia.

Por ejemplo, si queremos probar el flujo que muestra un formulario para agregar un nuevo registro desde la vista principal, necesitamos agregar un accessibility identifier al botón correspondiente. Esto nos permitirá:

Identificar el botón desde nuestro test
Hacer clic automáticamente en él
Verificar que el sheet del formulario se muestra correctamente

Es importante recordar que cada accessibility identifier debe ser único para cada elemento que queramos probar, aunque puede ser cualquier string que consideremos descriptivo.

¿Cómo implementar accessibility identifiers en tu código?

Para implementar estos identificadores en nuestro proyecto, debemos seguir estos pasos:

Identificar los elementos visuales que queremos probar
Asignar un accessibility identifier único a cada elemento
En algunos casos, crear identificadores dinámicos según el estado del elemento

Veamos algunos ejemplos prácticos:

// Para un título en la vista principal
.accessibilityIdentifier("upTitle")

// Para un botón de agregar registro
.accessibilityIdentifier("addRecordButton")

// Para filtros con estados seleccionado/no seleccionado
.accessibilityIdentifier("filter_\(filterName)_\(isSelected ? "selected" : "unselected")")

// Para tarjetas de ingresos y gastos
.accessibilityIdentifier("incomeCard")
.accessibilityIdentifier("outcomeCard")

// Para celdas de registros con identificadores dinámicos
.accessibilityIdentifier("record_\(record.id)")

// Para botones en vista de detalle
.accessibilityIdentifier("recordDetailDeleteButton")
.accessibilityIdentifier("recordDetailEditButton")

// Para título de formulario
.accessibilityIdentifier("formRecordTitle")

Estos identificadores nos permitirán localizar elementos específicos durante nuestras pruebas automatizadas y verificar que aparecen correctamente o interactuar con ellos.

¿Cómo configurar el entorno de pruebas para UI testing?

Además de agregar accessibility identifiers a los elementos visuales, necesitamos configurar nuestra aplicación para que utilice datos de prueba durante los UI tests, en lugar de datos reales.

Configuración del punto de entrada de la aplicación

Es necesario modificar el archivo principal de la aplicación (en este caso, GastifyApp) para que detecte cuándo se está ejecutando en modo de prueba:

init() {
    if ProcessInfo.processInfo.arguments.contains("UI_TEST") {
        // Usar base de datos mock para pruebas
        databaseService = MockDatabaseService()
    } else {
        // Usar base de datos real para uso normal
        databaseService = SDDatabaseService()
    }
}

Esta configuración garantiza que durante las pruebas de UI siempre utilizaremos datos simulados (mock), lo que nos permite tener un entorno controlado y predecible para nuestras pruebas.

Creación del archivo de pruebas UI

Para crear nuestras pruebas de UI, seguimos estos pasos:

Crear un nuevo archivo de prueba utilizando la plantilla XCTestUITest
Configurar el método setup para inicializar la aplicación en modo de prueba
Configurar el método tearDown para limpiar después de cada prueba

El código básico para configurar nuestro archivo de pruebas sería:

import XCTest

class HomeViewUITest: XCTestCase {
    
    var app: XCUIApplication!
    
    override func setUpWithError() throws {
        continueAfterFailure = false
        app = XCUIApplication()
        app.launchArguments.append("UI_TEST")
        app.launch()
    }
    
    override func tearDownWithError() throws {
        app = nil
    }
    
    // Aquí irán nuestros métodos de prueba
}

En este código:

Creamos una variable app que representa nuestra aplicación
En setUpWithError(), configuramos continueAfterFailure = false para que las pruebas se detengan si hay un error
Inicializamos la aplicación y le pasamos el argumento "UI_TEST" para que use datos mock
Lanzamos la aplicación con app.launch()
En tearDownWithError(), limpiamos la variable app

¿Qué elementos deberías probar en tu interfaz de usuario?

Al planificar tus pruebas de UI, considera incluir verificaciones para:

Elementos estáticos: Títulos, etiquetas y textos que siempre deben estar presentes
Elementos interactivos: Botones, campos de texto, switches que el usuario puede manipular
Flujos de navegación: Transiciones entre pantallas, presentación de modales o sheets
Estados visuales: Cambios en la interfaz según diferentes estados (seleccionado/no seleccionado)
Presentación de datos: Listas, tablas y colecciones que muestran información al usuario

Es recomendable agregar accessibility identifiers a todos los elementos que forman parte de los flujos críticos de tu aplicación, lo que te permitirá crear pruebas exhaustivas que validen el comportamiento esperado de tu interfaz.

La preparación adecuada de tu proyecto para UI testing es el primer paso crucial para implementar pruebas automatizadas efectivas. En las próximas etapas, podrás interactuar con estos elementos identificados y validar su existencia y comportamiento en las diferentes pantallas de tu aplicación. ¿Has implementado UI testing en tus proyectos? Comparte tu experiencia en los comentarios.

Resumen

¿Cómo preparar tu proyecto para UI testing?

¿Qué son los accessibility identifiers y por qué son importantes?

Identificar el botón desde nuestro test
Hacer clic automáticamente en él
Verificar que el sheet del formulario se muestra correctamente

Es importante recordar que cada accessibility identifier debe ser único para cada elemento que queramos probar, aunque puede ser cualquier string que consideremos descriptivo.

¿Cómo implementar accessibility identifiers en tu código?

Para implementar estos identificadores en nuestro proyecto, debemos seguir estos pasos:

Identificar los elementos visuales que queremos probar
Asignar un accessibility identifier único a cada elemento
En algunos casos, crear identificadores dinámicos según el estado del elemento

Veamos algunos ejemplos prácticos:

// Para un título en la vista principal
.accessibilityIdentifier("upTitle")

// Para un botón de agregar registro
.accessibilityIdentifier("addRecordButton")

// Para filtros con estados seleccionado/no seleccionado
.accessibilityIdentifier("filter_\(filterName)_\(isSelected ? "selected" : "unselected")")

// Para tarjetas de ingresos y gastos
.accessibilityIdentifier("incomeCard")
.accessibilityIdentifier("outcomeCard")

// Para celdas de registros con identificadores dinámicos
.accessibilityIdentifier("record_\(record.id)")

// Para botones en vista de detalle
.accessibilityIdentifier("recordDetailDeleteButton")
.accessibilityIdentifier("recordDetailEditButton")

// Para título de formulario
.accessibilityIdentifier("formRecordTitle")

Estos identificadores nos permitirán localizar elementos específicos durante nuestras pruebas automatizadas y verificar que aparecen correctamente o interactuar con ellos.

¿Cómo configurar el entorno de pruebas para UI testing?

Además de agregar accessibility identifiers a los elementos visuales, necesitamos configurar nuestra aplicación para que utilice datos de prueba durante los UI tests, en lugar de datos reales.

Configuración del punto de entrada de la aplicación

Es necesario modificar el archivo principal de la aplicación (en este caso, GastifyApp) para que detecte cuándo se está ejecutando en modo de prueba:

init() {
    if ProcessInfo.processInfo.arguments.contains("UI_TEST") {
        // Usar base de datos mock para pruebas
        databaseService = MockDatabaseService()
    } else {
        // Usar base de datos real para uso normal
        databaseService = SDDatabaseService()
    }
}

Esta configuración garantiza que durante las pruebas de UI siempre utilizaremos datos simulados (mock), lo que nos permite tener un entorno controlado y predecible para nuestras pruebas.

Creación del archivo de pruebas UI

Para crear nuestras pruebas de UI, seguimos estos pasos:

Crear un nuevo archivo de prueba utilizando la plantilla XCTestUITest
Configurar el método setup para inicializar la aplicación en modo de prueba
Configurar el método tearDown para limpiar después de cada prueba

El código básico para configurar nuestro archivo de pruebas sería:

import XCTest

class HomeViewUITest: XCTestCase {
    
    var app: XCUIApplication!
    
    override func setUpWithError() throws {
        continueAfterFailure = false
        app = XCUIApplication()
        app.launchArguments.append("UI_TEST")
        app.launch()
    }
    
    override func tearDownWithError() throws {
        app = nil
    }
    
    // Aquí irán nuestros métodos de prueba
}

En este código:

Creamos una variable app que representa nuestra aplicación
En setUpWithError(), configuramos continueAfterFailure = false para que las pruebas se detengan si hay un error
Inicializamos la aplicación y le pasamos el argumento "UI_TEST" para que use datos mock
Lanzamos la aplicación con app.launch()
En tearDownWithError(), limpiamos la variable app

¿Qué elementos deberías probar en tu interfaz de usuario?

Al planificar tus pruebas de UI, considera incluir verificaciones para:

Elementos estáticos: Títulos, etiquetas y textos que siempre deben estar presentes
Elementos interactivos: Botones, campos de texto, switches que el usuario puede manipular
Flujos de navegación: Transiciones entre pantallas, presentación de modales o sheets
Estados visuales: Cambios en la interfaz según diferentes estados (seleccionado/no seleccionado)
Presentación de datos: Listas, tablas y colecciones que muestran información al usuario

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

Preparación de Proyectos para UI Testing en iOS

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