Estructura de proyecto Android para testing

Antes de escribir tu primer test en Android, necesitas entender cómo se organiza un proyecto pensado para testing unitario y de instrumentación. Aquí desglosamos la arquitectura por capas, las librerías clave y la configuración de Gradle que conecta todo.

¿Cómo se organiza un proyecto Android orientado a testing?

El proyecto base, disponible en la rama class 3 configuration init del repositorio, sigue una arquitectura limpia con tres carpetas principales dentro del paquete test ground: data, domain y presentation. Cada una cumple un rol específico que más adelante facilitará aislar responsabilidades al testear.

¿Qué contiene la capa de data?

En data encuentras un UserApi construido con Retrofit. La interfaz expone tres endpoints, cada uno devolviendo un tipo distinto:

• getUser: recibe un userId y retorna un objeto User.
• getPlaces: usa el userId para traer una lista de lugares.
• getProfile: combina datos para devolver un perfil.

También vive aquí UserRepositoryImpl, una implementación realista de repositorio. Dentro de getProfile se usan coroutine builders como async para devolver un Deferred, manejar llamadas paralelas al endpoint y combinar el fetchUser con places para construir el perfil [02:00]. Si algo falla, se devuelve una respuesta de error controlada.

¿Qué define la capa de domain?

Domain agrupa las data classes que modelan el negocio: Place (con id, nombre y coordenadas de latitud y longitud), Profile (que envuelve un user y su lista de places) y User (id y username). También vive aquí la interfaz del repositorio, que define el contrato que la capa data implementa.

¿Qué hay en la capa de presentation?

La capa de presentación contiene el ProfileViewModel, que recibe un userId y dispara el llamado al repositorio para actualizar el estado, junto con ProfileScreen, un conjunto de composables que renderiza tres estados: cargando, error y perfil cargado.

¿Dónde van los tests unitarios y los de instrumentación?

Dentro del directorio de pruebas verás dos carpetas verdes cuando estás parado en la vista Android. La que aparece como com (test) aloja los tests unitarios, mientras que androidTest guarda los tests de instrumentación o end to end [04:30].

¿Cuál es la diferencia entre test y androidTest en Android? La carpeta test ejecuta pruebas en la JVM sin emulador, ideal para lógica pura. androidTest corre en un dispositivo o emulador y es donde van los tests de UI con Compose y los end to end.

¿Qué librerías de testing usaremos en el proyecto?

En el archivo libs.versions.toml ya están declaradas las versiones que vamos a necesitar. Cada librería resuelve un problema concreto del flujo de pruebas.

• JUnit: motor base para escribir y correr los tests unitarios.
• Mockk: librería para crear test doubles tipo mock, que veremos en la siguiente clase.
• MockWebServer: simula un servidor HTTP para probar la capa de red sin pegarle a una API real.
• Kotlin Coroutines Test: habilita funciones como runTest y runBlocking para evaluar corrutinas en entornos de prueba.
• Turbine: facilita probar Flow emitiendo valores de forma controlada.
• Truth: framework de assertions con sintaxis más legible que las aserciones clásicas de JUnit.
• Compose UI Test: permite hacer aserciones y verificaciones sobre composables.
• Navigation Testing: imprescindible cuando lleguemos al testing de navegación.

También aparecen Retrofit y OkHttp como dependencias de producción. OkHttp no se usa directamente en testing, pero ayuda a simular un entorno realista con interceptores y logging.

¿Para qué sirve MockWebServer? Es un servidor HTTP local que responde con datos que tú defines. Lo usas para probar tu capa de red sin depender de un backend real, asegurando que tu código maneja correctamente respuestas exitosas y de error.

¿Cómo se configuran las dependencias en Gradle según la carpeta de tests?

La palabra clave que usas en build.gradle decide en qué carpeta queda habilitada cada librería. Esta distinción es lo que evita que tus librerías de prueba contaminen el código productivo.

• implementation: la librería se usa en código productivo, dentro de main.
• testImplementation: habilita la librería solo en la carpeta test. Aquí van JUnit, Truth, Mockk, MockWebServer, Coroutines Test y Turbine.
• androidTestImplementation: habilita la librería en androidTest, donde sumamos Navigation Testing y Compose UI Test [07:20].

Los plugins relevantes son Hilt para inyección de dependencias, Room para persistencia y KSP para procesamiento de anotaciones. Nada fuera de lo común en un proyecto Android moderno.

¿Qué es packagingResources en la configuración de Android? Es un bloque dentro de la sección android del Gradle que evita conflictos de archivos duplicados al empacar. Si no lo habilitas, los tests pueden fallar con errores de recursos al compilar.

Con esta base lista, el siguiente paso es escribir tu primer unit test. Repasa cada librería del libs.versions.toml, investiga un dato que te llame la atención y compártelo en los comentarios.