Esta página describe lo que es posible ajustar para un módulo de suite ( AndroidTest.xml ) a través de 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 del uso de cada una.
Cuando se ejecuta continuamente una suite en el laboratorio, la suite generalmente se fragmenta 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.
¿Se puede fragmentar o no fragmentar?
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 desee anular ese comportamiento:
- Cuando la configuración de su módulo es costosa:
La fragmentación de un módulo da como resultado la preparación (instalar APK, enviar archivo, 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:
Al fragmentar un módulo, 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. Instalar un APK para un solo caso de prueba no suele valer la pena, 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 expone al arnés cuántas pruebas forman parte de la instrumentación hasta que instalamos y ejecutamos el APK. Estas operaciones son costosas y no se pueden ejecutar en el momento de fragmentación para todos los módulos que forman parte de la suite.
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 fragmentar ese módulo no vale la pena.
El corredor AndroidJUnitTest tiene una opción especial que le permite especificar la cantidad máxima de fragmentos en los que se permite fragmentar: <option name="ajur-max-shard" value="5" /> .
Esto le permite especificar un número máximo de veces que se puede fragmentar la instrumentación independientemente del número 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 ajur-max-shard de 2 garantizaría que no esté creando fragmentos vacíos.