Pruebas de snapshot para aplicaciones móviles: cómo funcionan, herramientas y ejemplos

¿Qué son las pruebas de snapshot?

Las pruebas de snapshot (pruebas de instantánea) son una técnica en la que una prueba renderiza un componente de la interfaz, guarda la imagen resultante como referencia y, en ejecuciones posteriores, compara el renderizado actual con esta referencia. Si las imágenes coinciden, la prueba pasa. Si se encuentran diferencias, la prueba falla y el desarrollador recibe una imagen diff con los píxeles modificados resaltados. La técnica fue tomada del desarrollo web (Jest snapshots) y adaptada para plataformas móviles.

El principal valor de las pruebas de snapshot es la detección automática de cambios visuales inesperados. Un desarrollador puede cambiar el esquema de colores en un tema global y afectar accidentalmente a una docena de pantallas. Las pruebas de UI que verifican la presencia de botones y textos no lo notarán. Una prueba de snapshot capturará cada cambio de píxel en cada pantalla afectada, proporcionando una imagen completa del impacto del cambio.

Según la encuesta del Mobile DevOps Summit 2023, los equipos que utilizan pruebas de snapshot además de las pruebas de UI clásicas reducen la cantidad de defectos visuales en los lanzamientos en un 40%. Este enfoque es especialmente efectivo en proyectos con sistemas de diseño y arquitecturas basadas en componentes, donde el cambio de un componente base puede afectar a docenas de pantallas de la aplicación.

Diferencias entre las pruebas de snapshot y las pruebas de UI

La diferencia fundamental radica en el objeto de verificación. Las pruebas de UI verifican la presencia, el estado y el comportamiento de los elementos de la interfaz: “el botón es visible”, “el texto contiene un mensaje de error”, “al presionar se abre una nueva pantalla”. Las pruebas de snapshot verifican la apariencia visual completa: la posición de los elementos, los márgenes, los colores, las fuentes, las sombras y los bordes redondeados. Una prueba de snapshot responde a la pregunta “¿la pantalla se ve como se espera?”, mientras que una prueba de UI responde “¿la pantalla funciona como se espera?”

La velocidad de ejecución también difiere. Las pruebas de UI se ejecutan en un emulador o dispositivo real, requieren la carga completa de la aplicación y tardan de 10 segundos a un minuto por escenario. Las pruebas de snapshot con bibliotecas como Paparazzi renderizan componentes en un entorno virtual sin iniciar un emulador, lo que reduce el tiempo de prueba a 100–500 milisegundos. Un conjunto completo de pruebas de snapshot (50–100 pantallas) se ejecuta en 2–5 minutos en lugar de 30–60 minutos para un conjunto comparable de pruebas de UI.

Sin embargo, las pruebas de snapshot no reemplazan a las pruebas de UI. La estrategia óptima es una combinación: las pruebas de snapshot cubren la regresión visual (renderizado de cada pantalla en estados básicos), mientras que las pruebas de UI cubren los aspectos de comportamiento (escenarios de clic, validación de entrada, navegación). Esta combinación proporciona un 90% de confianza en la corrección de la interfaz con un tiempo mínimo de ejecución en CI.

Herramientas para pruebas de snapshot

En Android, las herramientas principales son Paparazzi y Shot. Paparazzi de Cash App renderiza componentes en un entorno de prueba JVM sin emulador, utilizando el diseño de gravedad de Layoutlib. Shot de Karumi realiza capturas de pantalla de Instrumentation en un dispositivo real o emulador y las compara con las referencias mediante la biblioteca AShot, teniendo en cuenta las diferencias de resolución y densidad de píxeles.

Paparazzi para Android

Paparazzi no requiere iniciar un emulador: el renderizado se realiza en la JVM a través de Layoutlib, lo que ofrece una velocidad comparable a las pruebas unitarias. La biblioteca admite tanto el sistema View como Jetpack Compose. Para Compose, se usa el modificador paparazzi.snapshot { MyComposable() }. Las referencias se almacenan en src/test/snapshots y se comparan automáticamente en cada ejecución. El porcentaje máximo de diferencia se configura mediante maxPercentDifference.

SnapshotTesting para iOS

SnapshotTesting de Point-Free admite la comparación no solo de UIImage, sino también de cadenas, JSON, Data y tiendas enteras de Core Data. Esto la convierte en una herramienta versátil no solo para snapshots de UI, sino también para verificar la serialización y decodificación de respuestas JSON. Para SwiftUI, se usa la extensión assertSnapshot con el modificador .image(on: .iPhone13). La estrategia record: true crea referencias en la primera ejecución.

Enfoques multiplataforma

Para React Native, la solución popular es react-native-testing-library en combinación con jest-image-snapshot. El enfoque web de las pruebas de snapshot se traslada al entorno móvil mediante el renderizado de componentes en un entorno Node.js, seguido de la comparación de snapshots JSON del DOM virtual. Este enfoque es más rápido que el nativo, pero menos preciso: no tiene en cuenta las particularidades del renderizado de fuentes y componentes del sistema propios de cada plataforma. Para Flutter, se utilizan pruebas golden a través del toolkit goldens.

Ejemplos de código para pruebas de snapshot

Veamos pruebas de snapshot para Android (Paparazzi) e iOS (SnapshotTesting). Ambos ejemplos verifican la apariencia de un componente: una tarjeta de usuario con avatar, nombre y estado. La prueba renderiza el componente con datos de prueba y compara el resultado con una imagen de referencia almacenada en el repositorio.

Android: prueba de snapshot con Paparazzi

Paparazzi usa la anotación @Test y el método snapshot() para capturar el renderizado. Las referencias se guardan en la carpeta src/test/snapshots y se cargan automáticamente en la siguiente ejecución para su comparación.

class UserCardSnapshotTest {

    @get:Rule
    val paparazzi = Paparazzi(
        theme = "Theme.MyApp",
        maxPercentDifference = 0.1
    )

    @Test
    fun userCard_defaultState() {
        val card = UserCard(
            name = "Alice Johnson",
            status = "Online",
            avatarUrl = "https://example.com/avatar.png"
        )
        paparazzi.snapshot(card)
    }

    @Test
    fun userCard_offlineState() {
        val card = UserCard(
            name = "Bob Smith",
            status = "Offline",
            avatarUrl = null
        )
        paparazzi.snapshot(card, name = "user_card_offline")
    }
}

iOS: prueba de snapshot con SnapshotTesting

SnapshotTesting usa el modificador .snapshot() dentro de assertSnapshot. La biblioteca determina automáticamente el formato: UIImage para UIView, String para texto, Data para datos binarios.

import SnapshotTesting
import XCTest

class UserCardSnapshotTests: XCTestCase {
    func testUserCardDefaultState() {
        let card = UserCardView(
            name: "Alice Johnson",
            status: "Online",
            avatarURL: URL(string: "https://example.com/avatar.png")
        )
        let controller = UIHostingController(rootView: card)
        assertSnapshot(matching: controller, as: .image(on: .iPhone13))
    }

    func testUserCardOfflineState() {
        let card = UserCardView(
            name: "Bob Smith",
            status: "Offline",
            avatarURL: nil
        )
        assertSnapshot(matching: card, as: .image(on: .iPhone13))
    }
}

Flujo de trabajo de las pruebas de snapshot

Un flujo de trabajo típico incluye cuatro etapas. Primera ejecución (modo record): todas las pruebas de snapshot se ejecutan en modo de grabación: las imágenes de referencia se crean y se guardan en el repositorio. Esta etapa se realiza durante la configuración inicial de las pruebas o después de un cambio intencional en la interfaz. Después de la grabación, las referencias se confirman junto con el código y pasan a formar parte del proyecto.

En ejecuciones posteriores, las pruebas funcionan en modo de comparación: cada nuevo renderizado se compara con la referencia. Si se encuentran diferencias, se genera una imagen diff: los píxeles que coinciden con la referencia se resaltan en verde y los que difieren en rojo. El desarrollador revisa el diff y toma una decisión: si el cambio es esperado (cambio consciente de diseño), la referencia se actualiza con el comando record; si es inesperado, se corrige el error. La actualización de referencias se realiza con un solo comando: para Paparazzi es `./gradlew recordPaparazzi`, para SnapshotTesting es `assertSnapshot(record: true)`.

Según el Spotify Engineering Blog (2022), los equipos que utilizan el flujo de trabajo descrito dedican un promedio de 2 minutos por prueba al análisis de imágenes diff. Con un conjunto de 50 pruebas de snapshot, un ciclo completo de actualización de referencias toma entre 15 y 20 minutos, significativamente más rápido que la verificación manual de cambios visuales en 50 pantallas.

Limitaciones y antipatrones de las pruebas de snapshot

Las pruebas de snapshot tienen limitaciones fundamentales. Sensibilidad al entorno: un mismo componente puede renderizarse de forma diferente en distintas versiones del sistema operativo, densidades de pantalla y configuraciones de fuentes. Las referencias creadas en una máquina pueden diferir del renderizado en un servidor CI. La solución es usar parámetros de entorno fijos: una versión específica de Layoutlib para Paparazzi o un modelo exacto de dispositivo para SnapshotTesting.

Antipatrón n.º 1: snapshots gigantes: una prueba de snapshot que captura toda la pantalla falla ante cualquier cambio mínimo en cualquier componente. El enfoque correcto es probar componentes individuales (botón, tarjeta, campo de entrada) de forma aislada. Cada componente se prueba de forma independiente, lo que permite identificar con precisión la fuente del cambio. Antipatrón n.º 2: ignorar los diffs: actualizar automáticamente las referencias sin analizar las imágenes diff reduce el valor de las pruebas de snapshot a cero. Cada diff requiere una decisión consciente del desarrollador.

Según el Better Engineering Blog (2023), las pruebas de snapshot aportan el mayor valor cuando cubren componentes del sistema de diseño y pantallas clave en estados básicos: vacío, relleno, error y límite. Cubrir animaciones y estados dinámicos con pruebas de snapshot no es eficiente debido a la naturaleza no determinista de las marcas de tiempo en el renderizado; para estos escenarios, es más adecuada la grabación de video o la verificación manual de QA.