Lo que debes probar depende de factores como el tipo de app, el equipo de desarrollo, la cantidad de código heredado y la arquitectura usada. En las siguientes secciones, se describe lo que un principiante podría considerar cuando planifica qué probar en su app.
Organización de directorios de prueba
Un proyecto típico de Android Studio contiene dos directorios que contienen pruebas según su entorno de ejecución. Organiza las pruebas en los siguientes directorios como se describe:
- El directorio
androidTestdebe contener las pruebas que se ejecutan en dispositivos reales o virtuales. Estas pruebas incluyen pruebas de integración, de extremo a extremo y otras en las que la JVM por sí sola no puede validar la funcionalidad de tu app. - El directorio
testdebe contener las pruebas que se ejecutan en tu máquina local, como las pruebas de unidades. A diferencia de lo anterior, estas pueden ser pruebas que se ejecutan en una JVM local.
Pruebas de unidades esenciales
Cuando sigas las prácticas recomendadas, debes asegurarte de usar pruebas de unidades en los siguientes casos:
- Pruebas de unidades para ViewModels o presentadores.
- Pruebas de unidades para la capa de datos, especialmente los repositorios La mayor parte de la capa de datos debe ser independiente de la plataforma. Esto permite que los dobles de prueba reemplacen los módulos de bases de datos y las fuentes de datos remotas en las pruebas. Consulta la guía sobre cómo usar pruebas dobles en Android.
- Pruebas de unidades para otras capas independientes de la plataforma, como la capa Dominio, como sucede con los casos de uso y las interacciones.
- Pruebas de unidades para clases de utilidad, como manipulación de strings y matemáticas
Prueba de casos extremos
Las pruebas de unidades deben enfocarse tanto en casos normales como en extremos. Los casos extremos son situaciones poco comunes que los verificadores manuales y las pruebas más grandes no pueden detectar. Los siguientes son algunos ejemplos:
- Operaciones matemáticas con números negativos, cero y condiciones de límites
- Todos los posibles errores de conexión de red.
- Datos dañados, como JSON con formato incorrecto.
- Simula el almacenamiento completo cuando se guarda en un archivo.
- El objeto que se recrea en medio de un proceso (como una actividad cuando se rota el dispositivo).
Pruebas de unidades que se deben evitar
Algunas pruebas de unidades deben evitarse debido a su bajo valor:
- Pruebas que verifican el funcionamiento correcto del framework o una biblioteca, no tu código.
- Los puntos de entrada del framework, como actividades, fragmentos o servicios, no deben tener lógica empresarial, por lo que las pruebas de unidades no deben ser una prioridad. Las pruebas de unidades para actividades tienen poco valor, ya que abarcarían principalmente el código del framework y requieren una configuración más compleja. Las pruebas de instrumentación, como las pruebas de IU, pueden abarcar estas clases.
Pruebas de la IU
Hay varios tipos de pruebas de IU que debes emplear:
- Las pruebas de IU de pantalla verifican las interacciones críticas del usuario en una sola pantalla. Realizan acciones como hacer clic en botones, escribir formularios y verificar los estados visibles. Una clase de prueba por pantalla es un buen punto de partida.
- Pruebas de flujo de usuarios o pruebas de Navigation, que abarcan las rutas de acceso más comunes. Estas pruebas simulan cómo un usuario se mueve por un flujo de navegación. Son pruebas simples y útiles para verificar si hay fallas en el tiempo de ejecución durante la inicialización.
Otras pruebas
Hay pruebas más especializadas, como pruebas de captura de pantalla, pruebas de rendimiento y pruebas monkey. También puedes categorizar las pruebas por propósito, como las regresiones, la accesibilidad y la compatibilidad.
Lecturas adicionales
Para realizar pruebas aisladas, a menudo, debes reemplazar las dependencias del sujeto de prueba por dependencias falsas o simuladas, llamadas "dobles de prueba" en general. Continúa leyendo sobre ellos en Cómo usar dobles de prueba en Android.
Si quieres aprender a crear pruebas de IU y unidades, consulta los codelabs de prueba.