Pruebas E2E de aplicaciones Swift: de XCUITest a casos reales

¿Por qué las pruebas E2E son el "modo dios" para el desarrollador iOS?

Imagine: escribió un código Swift perfecto, todo compila, las pruebas unitarias están en verde. Lanza la versión y, una hora después, llegan los errores: el botón "Comprar" no se presiona en un iPhone 14 Pro, y en un iPad Mini la pantalla de inicio de sesión parece una pintura abstracta. ¿Le suena familiar? Aquí es donde entran en escena las pruebas E2E de Swift, la única manera de estar seguro de que su aplicación funciona como un reloj en manos de un usuario real.

Las pruebas End-to-End (E2E) simulan el escenario completo del usuario: desde iniciar la aplicación hasta completar la acción objetivo (compra, registro, envío de formulario). En este artículo, analizaremos cómo configurar XCUITest Swift para que sus pruebas no fallen por tonterías y el pipeline CI/CD no se convierta en un infierno.

Qué aprenderá:

\n
• Cómo escribir pruebas UI estables con XCUITest
\n
• Page Object Model para Swift: un ejemplo real
\n
• Manejo de operaciones asíncronas y esperas
\n
• Integración de pruebas E2E en CI/CD (GitHub Actions + Fastlane)
\n
• Top 3 errores de principiantes y cómo evitarlos
\n

Herramientas: qué necesitaremos

Para la automatización de pruebas Swift utilizamos tres pilares:

\n
1. XCUITest — el framework de Apple, integrado en XCTest. Permite emular gestos, verificar estados de elementos UI.
\n
2. Xcode Test Plan — para configurar esquemas de prueba (diferentes idiomas, orientaciones, datos).
\n
3. Fastlane + GitHub Actions — para ejecutar pruebas en CI.
\n

La sintaxis básica de XCUITest es simple: accede a la aplicación a través de XCUIApplication(), busca elementos mediante buttons["Login"] o textFields["email"] y emula acciones.

Escribiendo nuestra primera prueba E2E: escenario de inicio de sesión

Supongamos que tenemos una pantalla de inicio de sesión con los campos Email, Contraseña y un botón "Iniciar sesión". El objetivo: verificar que al ingresar datos correctos, el usuario navega a la pantalla principal.

import XCTest\n\nclass LoginE2ETests: XCTestCase {\n    \n    let app = XCUIApplication()\n    \n    override func setUpWithError() throws {\n        continueAfterFailure = false\n        app.launch()\n    }\n    \n    func testSuccessfulLogin() throws {\n        // 1. Encontramos los elementos\n        let emailField = app.textFields["emailTextField"]\n        let passwordField = app.secureTextFields["passwordTextField"]\n        let loginButton = app.buttons["signInButton"]\n        \n        // 2. Acciones del usuario\n        emailField.tap()\n        emailField.typeText("user@example.com")\n        \n        passwordField.tap()\n        passwordField.typeText("ValidPassword123")\n        \n        loginButton.tap()\n        \n        // 3. Verificamos el resultado\n        let dashboard = app.staticTexts["dashboardTitle"]\n        XCTAssertTrue(dashboard.waitForExistence(timeout: 5))\n    }\n}

Punto importante: use waitForExistence(timeout:) — sin esto, la prueba puede fallar si la animación o la solicitud de red se retrasan. Esto es la base de las pruebas E2E de Swift.

¿Por qué este código podría fallar?

\n
• El campo de entrada podría no ser el primer responder — agregue .tap() antes de typeText.
\n
• El botón podría estar cubierto por el teclado — use app.keyboards.buttons["Return"].tap().
\n
• Las etiquetas de texto pueden diferir según la localización — use siempre el Accessibility Identifier.
\n

Page Object Model (POM) para Swift: haciendo las pruebas más limpias

Cuando la aplicación crece, las pruebas se convierten en un desastre. La solución es el Page Object Model. Creamos clases separadas para cada pantalla, que encapsulan la lógica de búsqueda de elementos y acciones.

Ejemplo para la pantalla de inicio de sesión:

// Lo