Pruebas de integración en el desarrollo móvil — qué son, tipos y cómo se realizan

¿Qué son las pruebas de integración?

Las pruebas de integración son una etapa de verificación del software en la que se evalúa la corrección de la interacción entre módulos o subsistemas individuales de una aplicación. Mientras que las pruebas unitarias verifican cada componente de forma aislada, las pruebas de integración reúnen estos componentes y comprueban cómo funcionan en conjunto. Los escenarios típicos incluyen la transferencia de datos entre la capa de red y el repositorio, la escritura en una base de datos a través de ORM y el procesamiento de respuestas de API de terceros.

En el contexto del desarrollo móvil, las pruebas de integración cubren las interacciones entre la capa de UI, la lógica de negocio y las fuentes de datos. Por ejemplo, una prueba puede verificar que después de hacer clic en el botón “Iniciar sesión”, la aplicación envía una solicitud al servidor, recibe un token y lo guarda en el almacenamiento local. Dicha verificación confirma que la cadena de componentes funciona sin fallos.

Según el World Quality Report 2023, las empresas que aplican pruebas de integración de forma regular reducen el número de incidentes de producción en un 35% en comparación con los proyectos que solo dependen de pruebas unitarias. Esto convierte a las pruebas de integración en un elemento obligatorio de la estrategia de aseguramiento de la calidad en el desarrollo comercial.

Por qué son importantes las pruebas de integración en aplicaciones móviles

Las aplicaciones móviles constan de múltiples componentes interconectados: solicitudes de red, bases de datos locales, notificaciones push, servicios del sistema y SDK de terceros. Cada uno de estos componentes se desarrolla por separado, pero en tiempo de ejecución intercambian datos en tiempo real. Las pruebas de integración detectan defectos que no se pueden encontrar mediante la verificación aislada de módulos.

Entre los problemas típicos que descubren las pruebas de integración se incluyen la falta de coincidencia de tipos de datos entre la API y el modelo de la aplicación, errores de serialización JSON, manejo incorrecto de timeouts de red y fallos durante el acceso concurrente a la base de datos a través de Room o Core Data. Sin pruebas de integración, estos defectos llegan a producción y solo se manifiestan con usuarios reales.

La investigación del Google Testing Blog (2021) muestra que el costo de corregir un defecto encontrado durante las pruebas de integración es 5 veces menor que después del lanzamiento. Esto se debe a que en las primeras etapas el desarrollador tiene el contexto completo del error y puede corregirlo sin un ciclo urgente de hotfix. Invertir tiempo en escribir pruebas de integración se amortiza con la reducción de costos de mantenimiento y el aumento de la confianza de los usuarios.

Enfoques de las pruebas de integración

Existen tres enfoques principales para organizar las pruebas de integración: Big Bang, Bottom-Up y Top-Down. La elección de la estrategia depende del tamaño del proyecto, la arquitectura de la aplicación y la disponibilidad de los componentes en el momento de escribir las pruebas. Cada enfoque tiene sus ventajas y limitaciones que es importante considerar al planificar la cobertura de pruebas.

Big Bang

Big Bang — enfoque en el que todos los componentes del sistema se conectan simultáneamente, después de lo cual se ejecuta una ejecución de prueba general. Este método es simple de implementar: no es necesario escribir stubs ni emular módulos individuales. Sin embargo, cuando se detecta un error, es difícil determinar qué componente lo causó. Big Bang está justificado en proyectos pequeños con arquitectura simple donde el número de módulos no supera los cinco.

Bottom-Up

Bottom-Up — estrategia en la que las pruebas de integración comienzan con componentes de bajo nivel: base de datos, capa de red, servicios del sistema. Después de verificar cada nivel, las pruebas conectan gradualmente módulos de nivel superior — repositorios, clases Use Case y ViewModels. La principal ventaja es la detección temprana de defectos en las capas fundamentales de la aplicación, lo que reduce el riesgo de errores en cascada en etapas posteriores del desarrollo.

Top-Down

Top-Down — enfoque en el que las pruebas comienzan con componentes de nivel superior — pantallas de UI y navegación, mientras que los módulos de nivel inferior se simulan mediante stubs o mocks. Esto permite verificar escenarios de usuario antes de que el lado del servidor o la base de datos estén completamente implementados. Top-Down es especialmente útil durante el desarrollo paralelo de las partes cliente y servidor cuando el backend aún no está listo para la integración real.

Herramientas para pruebas de integración

Para las pruebas de integración de aplicaciones móviles se utiliza una serie de herramientas especializadas, divididas en tres categorías: bibliotecas para emulación de servidores, frameworks para trabajar con bases de datos y medios de verificación de servicios del sistema. La elección de la herramienta específica depende de la plataforma — Android o iOS — y del stack tecnológico del proyecto.

• MockWebServer — biblioteca de Square para Android que emula un servidor HTTP en un entorno de prueba. Permite establecer respuestas esperadas, verificar el cuerpo y los encabezados de las solicitudes, simular errores de red.
• OHHTTPStubs — biblioteca para iOS que intercepta solicitudes de red a nivel de NSURLProtocol y devuelve respuestas preparadas previamente. Admite demoras y errores de conexión.
• Room Testing — mecanismo incorporado de Android para probar la base de datos: crear una instancia de Room en memoria, realizar operaciones de lectura y escritura, verificar migraciones y disparadores.
• Core Data Testing — enfoque para iOS en el que se crea un contenedor de Core Data en memoria, lo que permite probar consultas, relaciones entre entidades y persistencia de datos sin almacenamiento permanente.

Ejemplos de código para pruebas de integración

Veamos ejemplos prácticos de pruebas de integración para Android e iOS. Para la plataforma Android utilizamos MockWebServer junto con JUnit, para iOS — XCTest con la biblioteca OHHTTPStubs. Ambos ejemplos verifican el escenario de recepción de datos de una API y su almacenamiento en un repositorio local.

Android: Pruebas de la capa de red con MockWebServer

Esta prueba verifica que una solicitud Retrofit al servidor emulado devuelve JSON correcto y que el repositorio convierte la respuesta en un modelo de dominio. MockWebServer intercepta la solicitud y devuelve el JSON especificado, tras lo cual la prueba compara el resultado esperado con el real.

class UserRepositoryTest {
    private val mockServer = MockWebServer()

    @Before
    fun setup() {
        mockServer.start()
    }

    @Test
    fun fetchUser_returnsCorrectData() {
        val json = "{ \`"id\`": 1, \`"name\`": \`"Alice\`" }"
        mockServer.enqueue(MockResponse()
            .setBody(json)
            .setResponseCode(200))

        val repository = UserRepository(
            createRetrofit(mockServer.url("/").toString()))
        val user = repository.fetchUser(1)

        assertEquals(1, user.id)
        assertEquals("Alice", user.name)
    }

    @After
    fun tearDown() {
        mockServer.shutdown()
    }
}

iOS: Pruebas de solicitudes API con OHHTTPStubs

Para iOS, una prueba similar utiliza OHHTTPStubs para interceptar solicitudes URL. La biblioteca reemplaza la respuesta del servidor a nivel del framework del sistema URL Loading System, lo que permite probar cualquier biblioteca de red — URLSession, Alamofire o Moya.

import XCTest
import OHHTTPStubs
import OHHTTPStubsSwift

class UserRepositoryTests: XCTestCase {
    func testFetchUser_returnsCorrectData() {
        stub(condition: isPath("/users/1")) { _ in
            return HTTPStubsResponse(
                jsonObject: ["id": 1, "name": "Alice"],
                statusCode: 200,
                headers: nil
            )
        }

        let repository = UserRepository()
        let expectation = expectation(description: "fetch user")

        repository.fetchUser(id: 1) { user in
            XCTAssertEqual(user.id, 1)
            XCTAssertEqual(user.name, "Alice")
            expectation.fulfill()
        }

        waitForExpectations(timeout: 2.0)
    }
}

Mejores prácticas de pruebas de integración

Las pruebas de integración efectivas requieren seguir un conjunto de prácticas que aumentan la estabilidad de las pruebas y reducen los costos de mantenimiento. Aísle las dependencias externas: use bases de datos en memoria en lugar de instancias de producción y emule API de terceros mediante bibliotecas de stubs. Esto elimina fallos no deterministas causados por la disponibilidad de la red o el estado de servicios externos.

Mantenga la independencia de las pruebas: cada prueba de integración debe funcionar de forma aislada, sin depender de los resultados de otras pruebas. Use las anotaciones @Before y @After en JUnit o setUp y tearDown en XCTest para preparar y limpiar el entorno de prueba. Esto evita la influencia mutua entre pruebas y simplifica el diagnóstico de errores.

Cubra los casos límite: las pruebas de integración deben verificar no solo los escenarios exitosos (happy path) sino también el manejo de errores — timeouts, códigos HTTP 4xx y 5xx, respuestas vacías, JSON malformado. Según el Google Testing Blog (2022), el 60% de los incidentes de producción están relacionados con un manejo incorrecto de casos límite que no fueron cubiertos por las pruebas.