Configuración de base de datos en memoria para pruebas Android

Optimizar la preparación de pruebas end-to-end implica simular el comportamiento real del usuario creando, visualizando y gestionando tareas dentro de una aplicación móvil. Esta solución parte del uso de una base de datos en memoria (Room) y de la configuración específica de la navegación en Android para asegurar un entorno controlado y reproducible.

¿Cómo adaptar la base de datos para pruebas confiables?

Para conseguir pruebas consistentes y aisladas, se configura una base de datos en memoria utilizando Room, integrada en la aplicación mediante inyección de dependencias con la librería Dagger Hilt. Este enfoque asegura que cada ejecución de prueba no interfiera con bases de datos productivas persistentes, evitando inconsistencias.

Para esto, es necesario hacer lo siguiente:

• Agregar las dependencias correspondientes (dependencies) en el archivo lives versions del proyecto y sincronizarlo.
• Crear un módulo específico (test data module) para configurar Room como base de datos en memoria únicamente para pruebas.
• Especificar en este nuevo módulo un reemplazo explícito del módulo original con @TestInstallIn y @SingletonComponent, para mantener la equivalencia estructural pero en un entorno aislado.
• Añadir allowMainThreadQueries para facilitar la manipulación directa durante pruebas.

¿Cómo implementar un test runner personalizado con Hilt?

Al trabajar con dependencias inyectadas en Android, especialmente utilizando Hilt, es importante personalizar el test runner inicial de la aplicación. Por defecto, Android utiliza AndroidJUnitRunner, pero con Hilt debemos crear nuestro propio runner que extienda del inicial y permita realizar pruebas con dependencias inyectadas.

Los pasos para esto son simples pero precisos:

• Crear un archivo de clase en el directorio específico de pruebas del proyecto (Android test).
• Al extender la clase AndroidJUnitRunner, proceder con la función sobreescrita newApplication que retorne una instancia de HiltTestApplication.
• Por último, actualizar en el archivo build.gradle de la aplicación el test instrumentation runner para que haga referencia a este nuevo runner.

¿Cómo mejorar la accesibilidad y testabilidad con content descriptions?

Añadir descripciones semánticas a nuestras interfaces, especialmente en los composables de Jetpack Compose, permite mejorar significativamente las capacidades de testing automatizado y accesibilidad:

• Añadir content description explícitas a botones como more_options, empty_task_state, o elementos de listas de tareas.
• Colocar identificadores claros y diferenciadores en pantallas y elementos interactivos (home_screen, task_screen, back_button, etc.).
• Incluir estas descripciones mediante modificadores semánticos (Modifier.semantics).

Este paso mejora además la accesibilidad móvil ayudando en navegación, interpretación por lectores de pantalla y facilita pruebas automáticas basadas en estas etiquetas o identificadores.

¿Te has enfrentado a situaciones complejas al configurar entornos de pruebas? Comenta cómo fue tu experiencia o si surgieron dudas en el proceso de implementación.