Pruebas en el desarrollo móvil: qué son, tipos y cómo organizarlas

Niveles de prueba: Unit, Integration, E2E

Pruebas unitarias

Las pruebas unitarias son la base de las pruebas de aplicaciones móviles. Verifican la unidad más pequeña de código — una función, método o clase de forma aislada del resto del sistema. En el desarrollo móvil, las pruebas unitarias se escriben en JUnit (Android) y XCTest (iOS). Una buena prueba unitaria debe ser rápida, independiente y repetible — no debe depender de la red, la base de datos o los componentes de la IU. Para el aislamiento se utilizan test doubles: mocks, stubs y fakes.

Mockito (Java/Kotlin) y MockK (Kotlin-first) son bibliotecas populares para crear objetos mock en Android. En iOS, se utilizan OCMock, Cuckoo o protocolos manuales. Regla: las pruebas unitarias deben cubrir la lógica de negocio y los modelos de datos. Las pruebas de IU no deben duplicar las pruebas unitarias — verifican la interacción del usuario con la interfaz.

Pruebas de integración

Las pruebas de integración verifican la interacción entre componentes: repositorio con base de datos, ViewModel con servicio API, navegación entre pantallas. A diferencia de las pruebas unitarias, las de integración utilizan dependencias reales o cercanas a la realidad (por ejemplo, base de datos en memoria o servidor mock). Robolectric es un framework para ejecutar pruebas de Android en JVM sin emulador, acelerando las pruebas de integración 10 veces.

Las pruebas de snapshot (Golden Tests) son un tipo especial de prueba de integración que comparan un componente de IU renderizado con una imagen de referencia (snapshot). Si la apariencia cambia, la prueba falla — el desarrollador ve qué cambió. Facebook SnapshotTestCase (iOS) y Shot (Android) son herramientas populares para pruebas de snapshot.

Pruebas E2E y de IU

Las pruebas E2E (end-to-end) verifican el escenario completo del usuario de principio a fin: inicio de la aplicación, inicio de sesión, realización de una acción, verificación del resultado. Las pruebas de IU son un subconjunto de E2E centrado en la interfaz. Herramientas: Espresso (Android), XCUITest (iOS), Detox (React Native). Las pruebas E2E son las más lentas, por lo que se ejecutan por separado en CI — normalmente en compilaciones nocturnas.

Herramientas iOS: XCTest y XCUITest

XCTest

XCTest es el framework integrado de Apple para pruebas unitarias de aplicaciones móviles. XCTestRunner ejecuta pruebas en el simulador o en un dispositivo real. Las pruebas heredan de XCTestCase, contienen setUp y tearDown para preparación y limpieza. XCTest incluye XCTAssert para aserciones (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) y XCTWaiter para esperar operaciones asíncronas.

Ejemplo de una prueba XCTest simple: crear un modelo User, verificar la corrección de la inicialización, el formato del nombre y el cálculo de la edad. Code Coverage en Xcode muestra qué líneas de código están cubiertas por las pruebas — el objetivo para proyectos comerciales: al menos 70–80% de cobertura de la lógica de negocio. XCTest está integrado con Xcode Server y sistemas CI a través de xcodebuild test.

XCUITest

XCUITest es el framework de Apple para pruebas de IU. Funciona a través de identificadores de accesibilidad: XCUIElementQuery encuentra botones, campos de entrada, tablas por label, identifier o tipo. XCUITest graba una secuencia de acciones (record/playback) y genera código de prueba. Importante: todos los elementos de la IU deben tener un accessibilityIdentifier para un funcionamiento estable de las pruebas.

Herramientas Android: JUnit, Espresso, Robolectric

JUnit y Mockito

JUnit es el framework básico para pruebas unitarias de aplicaciones móviles en Java/Kotlin. En Android se utilizan JUnit 4 (última versión estable 4.13.2) y JUnit 5 para nuevos proyectos. Mockito es una biblioteca para crear objetos mock: when(mock.method()).thenReturn(value) — un patrón estándar para aislar la clase probada de las dependencias.

Ejemplo de una prueba JUnit para Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso y UI Automator

Espresso es el framework de Google para pruebas de IU en Android. Espresso se sincroniza automáticamente con el hilo de la IU: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso es fácil de escribir y estable gracias a la espera incorporada del estado idle. UI Automator es un framework para pruebas entre aplicaciones que puede interactuar con elementos del sistema (diálogos de permisos, panel de notificaciones).

Herramientas multiplataforma: Detox, Appium

Detox para React Native

Detox es un framework E2E de caja gris para probar aplicaciones móviles React Native de Wix. Detox funciona en ambas plataformas desde una única base de código de pruebas, utilizando Espresso (Android) y XCUITest (iOS) internamente. Detox espera automáticamente a que la aplicación esté inactiva (sin animaciones, solicitudes de red, temporizadores) y solo entonces realiza la siguiente acción.

Appium

Appium es un framework multiplataforma universal que soporta Android, iOS, Web y aplicaciones híbridas. Appium utiliza el protocolo WebDriver y admite cualquier lenguaje de programación (Java, Python, JS, Ruby). Appium Server funciona como un servidor HTTP que traduce comandos a comandos nativos de UI Automator / XCUITest. La principal desventaja de Appium es la velocidad: las pruebas se ejecutan más lentamente que las nativas de Espresso o XCUITest.

TDD y BDD: metodologías de prueba

TDD: Test-Driven Development

TDD es una metodología de prueba de aplicaciones móviles donde el test se escribe antes del código de implementación. El ciclo Red-Green-Refactor: (1) escribir un test que falla (Red), (2) escribir el código mínimo para que el test pase (Green), (3) refactorizar el código manteniendo la aprobación del test. TDD proporciona un 100% de cobertura de pruebas para la nueva funcionalidad y una arquitectura limpia, ya que el test es la primera especificación del requisito.

BDD: Behaviour-Driven Development

BDD es una extensión de TDD donde los tests se escriben en lenguaje natural en formato Given-When-Then. Given (contexto) — When (acción) — Then (resultado esperado). Los tests BDD son comprensibles para todos los miembros del equipo: desarrolladores, testers, analistas y clientes. Mock vs Stub vs Fake: Mock verifica la interacción (si se llamó al método), Stub devuelve datos fijos, Fake es una implementación de trabajo simplificada (por ejemplo, BD en memoria). En IT Sectr, usamos TDD para la lógica de negocio crítica y BDD para los escenarios de aceptación.

Test Doubles es el nombre general para los objetos que reemplazan dependencias reales en los tests. Hay cuatro tipos: Dummy (objeto para llenar parámetros, no se usa), Stub (devuelve valores dados), Spy (registra llamadas para verificación), Mock (predefine llamadas esperadas). Comprender la diferencia es fundamental para un diseño de pruebas adecuado.

CI/CD y Device Farm

Automatización de pruebas en CI/CD

CI/CD — Integración Continua y Entrega Continua: la práctica de construir y probar automáticamente aplicaciones móviles con cada cambio de código. En el desarrollo móvil, el pipeline CI/CD incluye: linting, pruebas unitarias, pruebas de integración, compilación APK/IPA y pruebas de IU. GitHub Actions y Bitrise son plataformas populares para CI/CD móvil. Las pruebas deben ejecutarse rápido: pruebas unitarias en 1–2 minutos, de integración en 5–10, de IU en 15–30 minutos.

Device Farm

Device Farm es una granja de dispositivos reales para pruebas. Firebase Test Lab (Android) y Xcode Cloud (iOS) proporcionan acceso en la nube a cientos de modelos de dispositivos. Device Farm revela problemas no visibles en emuladores: diferentes tamaños de pantalla, rendimiento en dispositivos antiguos, problemas de compatibilidad. En IT Sectr, utilizamos Firebase Test Lab para Android y Xcode Cloud para iOS de forma regular.