Esta página describe lo que es posible ajustar para un módulo de suite ( AndroidTest.xml ) mediante fragmentación y obtener el mejor rendimiento de velocidad durante la ejecución continua en el laboratorio. Intentaremos describir las opciones de manera genérica con la justificación para usar cada una.
Cuando se ejecuta continuamente una suite en el laboratorio, la suite generalmente se divide en varios dispositivos para reducir el tiempo total de finalización. El arnés normalmente intenta equilibrar el tiempo de ejecución de cada fragmento para minimizar el tiempo de finalización general (cuando finaliza el último fragmento); pero debido a la naturaleza de algunas pruebas, no siempre tenemos suficiente introspección y necesitamos que el propietario del módulo ajuste algún comportamiento.
¿Divisible o no divisible?
Es posible etiquetar un módulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> para notificar al arnés que no debe fragmentarse.
En un módulo típico, dejar que el arnés fragmente su módulo (el comportamiento predeterminado) es lo correcto. Pero en algunos casos, es posible que desees anular ese comportamiento:
- Cuando la configuración de su módulo es costosa:
La fragmentación de un módulo da como resultado que la preparación (instalar APK, enviar archivos, etc.) posiblemente se ejecute una vez por dispositivo involucrado. Si la configuración de su módulo es larga y costosa y no vale la pena replicarla en comparación con el tiempo de ejecución de la prueba, debe etiquetar su módulo como no fragmentable.
- Cuando el número de pruebas en su módulo es bajo:
La fragmentación de un módulo da como resultado que todos los casos de prueba posiblemente se ejecuten de forma independiente en diferentes dispositivos. Esto se relaciona con el primer punto; Si su número de pruebas es bajo, podría terminar con una sola prueba o ninguna prueba en algunos fragmentos, lo que haría que cualquier paso de preparación fuera bastante costoso. Por lo general, no vale la pena instalar un APK para un solo caso de prueba, por ejemplo.
Pruebas de instrumentación: ¿Número máximo de fragmentos?
Una prueba de instrumentación que se ejecuta a través de AndroidJUnitTest no muestra cuántas pruebas forman parte de la instrumentación hasta que realmente instalamos y ejecutamos el APK. Estas operaciones son costosas y no se pueden ejecutar en el momento de la fragmentación de todos los módulos que forman parte del conjunto.
El arnés podría fragmentar demasiado la prueba de instrumentación y terminar con algunos fragmentos vacíos; fragmentar una prueba de instrumentación con cinco pruebas en seis fragmentos da como resultado cinco fragmentos con una prueba y un fragmento sin pruebas. Cada uno de estos fragmentos requeriría una costosa instalación de APK.
Entonces, cuando la cantidad de pruebas en el APK de prueba de instrumentación es baja, etiquetar el módulo con <option name="not-shardable" value="true" /> permitiría que el arnés sepa que no vale la pena fragmentar ese módulo.
El ejecutor AndroidJUnitTest tiene una opción especial que le permite especificar la cantidad máxima de fragmentos en los que puede fragmentar: <option name="ajur-max-shard" value="5" /> .
Esto le permite especificar una cantidad máxima de veces que se puede fragmentar la instrumentación independientemente de la cantidad de fragmentos solicitados en el nivel de invocación. De forma predeterminada, la instrumentación se fragmentará en la cantidad de fragmentos solicitados para la invocación.
Por ejemplo, si su APK de prueba de instrumentación contiene solo dos casos de prueba pero aún desea fragmentarlo, tener un valor ajur-max-shard de 2 garantizaría que no esté creando fragmentos vacíos.