Screenshot Test: qué es, tipos y cómo funciona en pruebas

¿Qué es Screenshot Test y para qué sirve?

Screenshot Test es una prueba de interfaz de usuario end-to-end donde el test abre una pantalla de la aplicación, realiza acciones (toques, entrada de texto, desplazamiento) y toma una captura de pantalla del estado resultante. La captura se compara con una referencia (baseline) almacenada en el repositorio. Si las capturas difieren — la prueba falla. Las screenshot tests detectan regresiones visuales que las unit tests no pueden ver: márgenes incorrectos, elementos superpuestos, colores equivocados.

¿Por qué necesitamos screenshot tests si tenemos golden tests? — las golden tests verifican componentes de forma aislada: un botón, una tarjeta, un texto. Las screenshot tests verifican una pantalla completa en un entorno lo más cercano posible a producción: navegación real, datos reales (o mocks lo más realistas posible), fuentes del sistema reales, barra de estado real. Solo una screenshot test mostrará que un botón se superpone con otro elemento en un dispositivo real.

Valor empresarial de las screenshot tests

Valor empresarial — según Google (2023), los bugs visuales representan el 15-25% de todos los bugs en aplicaciones móviles. Las screenshot tests automatizan la verificación de calidad visual que antes realizaban manualmente los ingenieros de QA. Una screenshot test reemplaza 5-10 minutos de pruebas manuales de una pantalla. Para una aplicación con 50 pantallas, ahorro: 4-8 horas-persona por ejecución de regresión. Las screenshot tests se amortizan en 2-3 ciclos de lanzamiento.

Screenshot Test vs Golden Test: comparación de enfoques

Las golden tests son más rápidas y simples: renderizar un componente en un buffer fuera de pantalla toma milisegundos, no requiere dispositivo y es estable en CI. Las screenshot tests son más realistas: capturan una pantalla real con elementos del sistema, soportan animaciones y navegación, y funcionan en dispositivos reales. La elección depende del objetivo: retroalimentación rápida para el desarrollador (golden) o máximo realismo antes del lanzamiento (screenshot).

Estrategia de cobertura: golden + screenshot

Golden + Screenshot — use golden tests para cada componente de IU en la biblioteca de componentes (Design System). El 80% de las regresiones visuales se detectan a nivel de componentes. Screenshot tests — para rutas críticas de usuario: onboarding, inicio de sesión, flujo de pago, carrito de compras. El 20% de las regresiones relacionadas con la integración de componentes en una pantalla real solo se detectan con screenshot tests. En IT Sectr usamos una proporción 80/20: 400 golden + 100 screenshot.

Cuándo no se necesita una screenshot test — si la pantalla consiste en contenido estático sin interactividad, una golden test del componente proporciona el mismo nivel de verificación a un menor costo. Si la pantalla cambia dinámicamente (feed, chat), una screenshot test requiere una configuración compleja de datos y tiempos de espera. En tales casos, use screenshot para el estado base (lista vacía, carga) y golden para tarjetas individuales en la lista.

UI Automator y Firebase Test Lab para Android

UI Automator es un framework de Android para pruebas de IU entre aplicaciones. Permite tomar capturas de pantalla mediante UiDevice.takeScreenshot(). A diferencia de Espresso (funciona dentro de una sola aplicación), UI Automator puede interactuar con diálogos del sistema (permisos, notificaciones) y otras aplicaciones. Una screenshot test con UI Automator: abrir la app, esperar la carga, tomar captura, comparar con referencia.

class LoginScreenScreenshotTest {

    @get:Rule
    val rule = ComposeTestRule.createAndroidComposeRule<MainActivity>()

    @Test
    fun login_screen_default() {
        val device = UiDevice.getInstance(
            InstrumentationRegistry.getInstrumentation()
        )

        // Esperamos a que cargue la pantalla
        IdlingRegistry.getInstance().waitForIdle()

        // Tomamos una captura de pantalla
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Comparamos con la referencia
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab es un servicio de Google Cloud para ejecutar pruebas instrumentadas en cientos de dispositivos reales en paralelo. Las screenshot tests en Firebase Test Lab capturan pantallas en diferentes dispositivos (Pixel 7, Galaxy S24, Xiaomi 14) y las comparan con referencias. Ventaja: una prueba verifica la IU en 20 dispositivos en 10-15 minutos. Desventaja: costo ($1-5 por prueba en 20 dispositivos). Firebase Test Lab se integra con CI mediante gcloud CLI o el plugin de Gradle.

Shot: biblioteca para simplificar screenshot tests

Shot es una biblioteca para screenshot testing en Android que facilita la creación y comparación de capturas. Shot funciona sobre Espresso y UI Automator, añadiendo gestión de golden (crear, actualizar, eliminar), comparación con umbral (píxeles o porcentajes) y generación de informes HTML. Shot es adecuado para proyectos que quieren implementar rápidamente screenshot testing sin escribir su propia infraestructura de comparación de imágenes.

XCUITest y Xcode Cloud para iOS

XCUITest es el framework de Apple para pruebas de IU de aplicaciones iOS, iPadOS y tvOS. Las screenshot tests en XCUITest usan XCUIScreen.main.screenshot() para capturar la pantalla y XCAttachment para guardar las capturas. XCUITest simula acciones de usuario: tap, swipe, typeText, y toma capturas después de cada paso. En Xcode 16+ se ha añadido soporte integrado para comparación de capturas con referencias mediante XCTAttachment.

final class LoginScreenScreenshotTests: XCTestCase {

    var app: XCUIApplication!

    override func setUp() {
        super.setUp()
        app = XCUIApplication()
        app.launch()
    }

    func test_login_initial_state() {
        let loginButton = app.buttons["login_button"]
        XCTAssertTrue(loginButton.exists)

        // Tomamos una captura de pantalla
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Comparación con la referencia (requiere XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud es el CI en la nube de Apple para compilar y probar aplicaciones iOS. Xcode Cloud admite la ejecución de tests XCUITest en simuladores. Las screenshot tests pueden ejecutarse en múltiples simuladores en paralelo (iPhone 15, iPhone 15 Pro Max, iPad Pro). Resultados: XCResult Bundle con adjuntos. Xcode Cloud no está integrado en GitHub/GitLab — use Xcode Cloud Webhooks para la integración. Alternativa: GitHub Actions con macos-14 y xcodebuild.

Frameworks de comparación — iOSSnapshotTestCase (Uber) también funciona para screenshot tests si se ejecuta en un simulador. SwiftSnapshotTesting (pointfree) está más orientado a golden tests de componentes. Para screenshot tests en iOS, use las herramientas integradas de XCUITest + XCTAttachment + un ImageComparator personalizado (Pixelmator o AImage). En CI use simulador — en dispositivos reales las screenshot tests solo funcionan a través de Device Farm (AWS Device Farm).

Proceso de automatización de screenshot tests en CI

Gestión de baselines — las capturas de referencia se almacenan en el repositorio (Git LFS) o en S3. Cada captura se nombra según la plantilla: {testName}_{device}_{orientation}_{locale}.png. Ejemplo: loginScreenPixel7PortraitRu.png. Al añadir un nuevo dispositivo o configuración regional, se crea una nueva referencia. Al cambiar la IU, las referencias antiguas se reemplazan por nuevas después de la revisión de código. La referencia es parte de la base de código, como los fuentes de las pruebas.

Pipeline CI — (1) Compilar la aplicación. (2) Ejecutar screenshot tests en emuladores/simuladores. (3) Comparar capturas con referencias. (4) En caso de discrepancia — generar imagen diff. (5) Subir artefactos diff (actual, esperado, diff — tres archivos). (6) Publicar informe HTML con tabla de resultados. (7) Si se supera el umbral — la prueba falla. (8) El revisor examina los artefactos diff y toma una decisión: aprobar (actualizar referencia) o rechazar (corregir código).

Umbral y tolerancia — la comparación absoluta píxel a píxel es demasiado estricta. Use SSIM (Índice de Similitud Estructural) o MSE (Error Cuadrático Medio). SSIM 0.98 = 98% de similitud estructural — un buen umbral. Diferentes pantallas pueden requerir diferentes umbrales: tema oscuro (más negro — mayor precisión), degradados (más ruido — menor precisión). Configure el umbral por prueba mediante el parámetro: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulador — las pruebas en dispositivos reales (Firebase Test Lab, AWS Device Farm) ofrecen máximo realismo pero son lentas y de pago. Las pruebas en simuladores/emuladores son rápidas y gratuitas pero no muestran características de dispositivos reales (diferentes GPUs, reproducción de color de pantalla, densidad de píxeles). Estrategia: simulador para verificación pre-merge (5 minutos), Device Farm para nocturnas (30 minutos, 20 dispositivos). En IT Sectr usamos Firebase Test Lab para ejecuciones nocturnas en los 10 dispositivos Android principales.