En esta página, se describe lo que se puede ajustar para un módulo de suite
(AndroidTest.xml) a través del fragmentación y obtener el mejor rendimiento de velocidad durante la
ejecución continua en el lab. Intentaremos describir las opciones de forma genérica con la justificación para usar cada una.
Cuando se ejecuta de forma continua un paquete en el lab, este suele fragmentarse en varios dispositivos para reducir el tiempo de finalización general. Por lo general, el harness intenta equilibrar el tiempo de ejecución de cada fragmento para minimizar el tiempo de finalización general (cuando finaliza el último fragmento). Sin embargo, debido a la naturaleza de algunas pruebas, no siempre tenemos suficiente introspección y necesitamos que el propietario del módulo ajuste algunos comportamientos.
¿Se puede particionar o no?
Es posible etiquetar un módulo (AndroidTest.xml) con <option name="not-shardable" value="true" /> para notificar al agente que no debe fragmentarse.
En un módulo típico, lo correcto es permitir que el arnés fragmente tu módulo (el comportamiento predeterminado). Sin embargo, en algunos casos, es posible que desees anular ese comportamiento:
- Cuando la configuración de tu módulo es costosa:
La fragmentación de un módulo hace que la preparación (APK de instalación, archivo push, etc.) se ejecute una vez por dispositivo involucrado. Si la configuración de tu módulo es larga y costosa, y no vale la pena replicarla en comparación con el tiempo de ejecución de la prueba, debes etiquetar tu módulo como no particionable.
- Cuando la cantidad de pruebas en tu módulo es baja:
La fragmentación de un módulo hace que todos los casos de prueba se ejecuten de forma independiente en diferentes dispositivos. Esto se relaciona con el primer punto. Si la cantidad de pruebas es baja, es posible que termines con una sola prueba o sin ninguna en algunos fragmentos, lo que haría que cualquier paso de preparación fuera bastante costoso. Por ejemplo, por lo general, no vale la pena instalar un APK para un solo caso de prueba.
Pruebas de instrumentación: ¿Cantidad máxima de fragmentos?
Una prueba de instrumentación que se ejecuta a través de AndroidJUnitTest no expone al harness 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 la fragmentación para todos los módulos del paquete.
Es posible que el harness fragmente demasiado la prueba de instrumentación y termine con algunos fragmentos vacíos. Si fragmentas una prueba de instrumentación con cinco pruebas en seis fragmentos, se generarán cinco fragmentos con una prueba y un fragmento sin pruebas. Cada uno de estos fragmentos requeriría una instalación de APK costosa.
Por lo tanto, 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 harness sepa que no vale la pena particionar ese módulo.
El ejecutor AndroidJUnitTest tiene una opción especial que le permite especificar la cantidad máxima de fragmentos en los que se puede dividir: <option name="ajur-max-shard" value="5" />.
Esto te permite especificar una cantidad máxima de veces que se puede fragmentar la instrumentación, independientemente de la cantidad de fragmentos solicitados a nivel de la invocación. De forma predeterminada, la instrumentación se dividirá en la cantidad de fragmentos solicitados para la invocación.
Por ejemplo, si tu APK de prueba de instrumentación contiene solo dos casos de prueba, pero aún deseas fragmentarlo, tener un valor ajur-max-shard de 2 garantizaría que no se creen fragmentos vacíos.